HPE Storage Users Group

Hello!
First time posting here and being beginner on 3PAR as well. We're moving from a EVA 4400 to a 7200c with 24x 480 GB SSD with a single CPG containing a number of tdvv's published to either a 3-host vsphere environment (running VMFS5) or single server blades running NTFS directly on the vv.

We have very poor dedup ratio, on average 1.2. I have understand that part of the reason for this is that all our NTFS volumes (regardless within VM's on VMFS or directly on vv) are default 4KB cluster size, many were not defrag:ed or zeroed out before migrated, but also the fact that some servers, like SQL-servers just cannot be deduped much at all.

I was suggested by HP support to create a second CPG with only tpvv's and try to put non-dedup-friendly systems like Exchange and SQL there, leaving the original CPG with tdvv.

We're soon about to install MS Exchange on both a VM and a physical server, this time doing it right on 64KB cluster size. Is it worth using non-standard settings on this second CPG, like 512KiB step size as recommended per 3PAR Exchange whitepaper?

Does this sound like a good idea to you? Should I even consider moving virtualised SQL-servers data volumes over there too, away from the deduped CPG?

Anything else worth knowing?

Kind regards
Magnus

Overall dedupe values are based on an average across the CPG since dedupe volumes share common space, so putting non dedupable volumes or thin volumes in a dedupe CPG will bring down the overall dedupe ratio. The savings will still occur its just they won't be so obvious from the ratio. The best method of measuring the real savings compaction and dedupe is to look at what the hosts think they've written at the file system and what the CPG has actually written.

Dedupe values are calculated differently by every vendor , some include zero detect in DD ratios, HP don't. So, don't get too hung up on the reported numbers as it only reflects the arrays view at the backend, not the front end host view. Also look holistically dedupe isn't the only saving mechanism, compaction reflects the more realistic overall saving

I am yet to try dedupe, might try it on the arrays im installing next week, but I rarely believe the figures the manufacturers give, they are normally heavily massaged.

SQL won't dedupe well, it does compress well though.

Where you get good dedupe from is os disks in vmware, and better still if they are all deployed from the same image, also most figures are assuming you're using vdi which increases the ratio massively.

The hp dedupe is using a pretty big block size too I think, hp reckon that's because their research shows that's what the average block is in vmware, but I'm sure if they could do it with a smaller block size inline and not have performance issues then they would do it.

Dedupe is in its infancy though really on a 3par in the grand scheme of things.

Smaller block sizes don't help that much in the grand scheme of things (outside powerpoint), but they do generate more metadata for mapping and more garbage collection requirements. You're correct databases don't dedupe very well and yes they do compress, but many already have optimal compression built in anyway. In larger database environments many Customers require multiple physical copies of the same database and dedupe can help there as it's across copies rather than within the database.

Bottom line is dedupe will vary by data type, customer, setup and is likely to erode over time so no one can provide real guarantees. In reality a higher dedupe ratio is only beneficial if it saves you money vs the other guy.

e.g if buying 10TB's of usable with an assumed 4:1 dedupe (40TB effective) from vendor A costs you the same as 20TB's @ 2:1 from vendor B then you'd be better going with the 2:1 config as you run less risk of a future shortfall and get more SSD's into the bargain and hence more performance for the same price. Also think about upgrades even with a great dedupe ratio you have to think about futures, can I mix new with old as the price reduces over time, what's my minimum upgrade, a couple of drives, another full enclosure or another appliance ?

3PAR use 16kb dedupe blocks and this is the recommended cluster size for all filesystems when using thin dedupe VV.
It makes sense as the array already is working on 16 kb page size.

There is a doc out there explaining the reasoning to stay on 16kb,
according to that there is not that much benefit of moving to 4k pages for dedupe.
And I assume there is a performance limit on the ASIC on the number of hashing comparisons they are able to perform as well.

Thanks for the input!

So, if I understand you all correctly, having non-dedupable data on tdvv's doesn't actually hurt the ability or efficiency to dedup in general, it just makes less nice numbers?

Still, I assume I can spare unnecessary processing overhead by putting known non-dedupable data on tpvv's instead of tdvv's?

Finally, there is actually VERY little benefit of putting the tpvv's in different CPG, separated for the tdvv's? Apart form the possibility to have other CPG-settings than the original CPG, the only thing I will accomplish is a slightly higher average "dedupe-score" for the whole cpg? Wich again is pretty much cosmetic and have no realworld impact on savings?

I've made new VM templates in vSphere based on 16kb cluster size and I will be encouraging my collegues to make 64kb NTFS volume for MS SQL and MS Exchange and 16kb for everything else.

Best regards
Magnus

So, if I understand you all correctly, having non-dedupable data on tdvv's doesn't actually hurt the ability or efficiency to dedup in general, it just makes less nice numbers?

Correct, poor dedupe ratios will bring down the overall reported average.

Still, I assume I can spare unnecessary processing overhead by putting known non-dedupable data on tpvv's instead of tdvv's?

Correct, there's no point wasting dedupe cycles on data you know won't dedupe you'll just increase latency, that's why there's the dedupe estimation tool. Dedupe carries some overhead on every platform and since 3PAR can turn this on or off it's actually a huge advantage vs the always on brigade, where they must always incur additional latency for such data.

Finally, there is actually VERY little benefit of putting the tpvv's in different CPG, separated for the tdvv's? Apart form the possibility to have other CPG-settings than the original CPG, the only thing I will accomplish is a slightly higher average "dedupe-score" for the whole cpg? Wich again is pretty much cosmetic and have no realworld impact on savings?

Correct, but for your own sanity you may want to keep them separate as it makes for easier reporting / troubleshooting etc.