HPE Storage Users Group
https://3parug.net/

Real life data reduction rates on 8450, 9450 and performance
https://3parug.net/viewtopic.php?f=18&t=3011
Page 1 of 2

Author:  mrwillows [ Mon Oct 15, 2018 12:05 pm ]
Post subject:  Real life data reduction rates on 8450, 9450 and performance

Hi,

I'm currently looking to replace couple of older 3PARs along with some other arrays.
the 3PARs (8200, 7200c) are all running 3.2.2 and only using dedupe on couple of volumes on the 8200 with not-so-good experience (latency spikes, etc).

I was hoping to find someone here that is running compression (and maybe dedupe) on large 8450 or 9450 systems and was ratio people see in the field.

Some of the systems we are looking to replace are Nimble Storage and there we have like ~3.5:1 reduction on huge Oracle volumes. I'm mostly worried about seeing performance issues with the data reduction services on on the 3PAR since it seems like compression (and dedupe) is a bolt-on solution (not like the Nimbles were compression was always part of the product).

Can anyone here share some info on this? I don't want to see the made up numbers ;-)

Thanks in advanced!

Author:  MammaGutt [ Tue Oct 16, 2018 3:55 am ]
Post subject:  Re: Real life data reduction rates on 8450, 9450 and perform

Not sure where to start, but you seem to be looking at the right things.

Compression is "standard". Ref https://h20195.www2.hpe.com/V2/GetPDF.a ... 358enw.pdf https://blog.purestorage.com/pure-stora ... reduction/ http://recoverymonkey.org/2018/05/23/ne ... -and-nvme/ 3PAR uses LZ4, Pure uses LZ0 and Nimble use LZ4 on older arrays and LZ4 + something else for newest models. So if you have 3.5:1 on an older Nimble you should expect the same on a 3PAR. Not sure how Nimble produces the 3.5:1 figure though .. Could be that they count zero blocks into those numbers to inflate them as many others in the industry does, but most likely they are inflating dedupe in stead.

LZ4 provides the best performance all over, but provides a slightly lower compression ratio over LZ0. LZ0 provides generally the same compression speed as LZ4 but decompression is slower.

LZ4 is genrally chosen for use cases where performance is key.

Now, from a birds eye view, the 8450 and 9450 seems to be rather similar... But if you take a deeper look at the quickspec you will see that a 9450 has 2x ASICs and 2x CPUs per node, while the 8450 only has one. 2.3333x the cache isn't bad thing either....

As for real numbers to share you are very vague... You have 7200c and 8200, what do you consider a large 9450? 2TB RAW (256*7.68TB SSD) capacity or 200TB (48*3,84TB SSD)

Author:  mrwillows [ Tue Oct 16, 2018 5:06 am ]
Post subject:  Re: Real life data reduction rates on 8450, 9450 and perform

Hi,

Thanks for taking the time to answer.

I don't think the Nimble units count in zeroes. Oracle seems to compress extremly well.

I would count a system larger then 300-400TB raw large....usable capacity could be around ~550-650TB.
Hoping to replace all of my current arrays (7200c,8200, hybrid Nimble on one site, 7200c, 8200, all flash Nimble and a hybrid one on other) with a single large one if possible. I am sure that the 9450 has enough horsepower to replace those (I am currently bound by the CPUs in the Nimble and the SAS backend on the 8200).

It would be very interesting to see data reduction numbers from system running Oracle, MSSQL and VMware workloads.

Thanks in advanced.

Author:  SBrayne [ Tue Oct 16, 2018 5:26 pm ]
Post subject:  Re: Real life data reduction rates on 8450, 9450 and perform

One of our 8440 has ~800TB Raw, ~50% used
Running 3.3.1 MU2

Had issues with dedupe on 3.2.2 and early 3.3.1, but 3.3.1 MU2 has been great

Volumes are grouped in CPGs by function, production systems only.
Here are the real numbers from the several CPGs we have:

Name Data Size Dedupe Compr. Overall
Oracle 15TB 1.8 1.6 2.5
Exchange 8TB 1.6 1.3 1.9
VMWare(Inc. small SQL) 74TB 1.6 1.4 2.1
VDI (Windows 7) 7TB 3.8 1.4 4.8
Fileservers 39TB 1.2 1.2 1.4
VMWare (Large SQL) 72TB 1.4 1.1 1.4
Enterprise Vault 42TB 1.0 1.0 1.0

Overall system reduction: 1.4 1.4 1.9

Let me know if there is anything else you would like to know.

Author:  mrwillows [ Thu Nov 01, 2018 4:04 pm ]
Post subject:  Re: Real life data reduction rates on 8450, 9450 and perform

@SBrayne:

Out of curiosity ...what is the IO profile of the Oracle / SQL volumes and what are your r/w response times on that 8450? I have some evil workload bashing my arrays with large IOs that push my 8200 its limits (20-30ms response times on all SSD volumes while pushing some 3000-4000 IO of around 500K+ size). Interested to hear from other users with large DBs doing large IO (preferably using in-line compression).

Author:  MammaGutt [ Fri Nov 02, 2018 3:02 am ]
Post subject:  Re: Real life data reduction rates on 8450, 9450 and perform

8200 with compression and high IO will give high latency.

2node 8440/8450 would have been a lot better performer.

Author:  mrwillows [ Fri Nov 02, 2018 3:15 am ]
Post subject:  Re: Real life data reduction rates on 8450, 9450 and perform

MammaGutt wrote:
8200 with compression and high IO will give high latency.

2node 8440/8450 would have been a lot better performer.



Yep - that is true. However I don't run compression on these volumes (only running 3.2.2 MU6 on those 8200). So I would really like to hear from someone running these workloads on a larger 8000 or even 9000 3PAR. Preferably with data reduction features enabled.

Author:  Chris212 [ Thu Nov 08, 2018 2:49 am ]
Post subject:  Re: Real life data reduction rates on 8450, 9450 and perform

I would not go with 3par. You only need to check the release notes of 3.3.1 MU2 and MU3 and hundreds of critical issues that were corrected.

At least i strongly recommend not to go with the 8*** family as we are facing (8200 nodes) issues with CPU being "too short" to use compression properly (and we use it only for DB volumes).

Author:  finnzi [ Sat Nov 10, 2018 3:50 am ]
Post subject:  Re: Real life data reduction rates on 8450, 9450 and perform

Chris212 wrote:
I would not go with 3par. You only need to check the release notes of 3.3.1 MU2 and MU3 and hundreds of critical issues that were corrected.

At least i strongly recommend not to go with the 8*** family as we are facing (8200 nodes) issues with CPU being "too short" to use compression properly (and we use it only for DB volumes).


Valid points. And the code issues in 3.3.1 have been a joke from a QA perspective.

But at least HPE are up-front about the issues and keep a changelog out in the open. That should be respected.

Bgrds,
Finnzi

Author:  Marc.mvh.vanhoof [ Sat Nov 10, 2018 4:26 am ]
Post subject:  Re: Real life data reduction rates on 8450, 9450 and perform

Hi to all. Starting this year we compressed 2 x 8450 systems (all VV's) and ratio was 2/1! That was the good news. After a few days we run into the (read LD error issue) and decided to go back to not compressed. All convertion was done by tunevv and in that way it was not that much work. Performance during and after compression was ok. Now running 3.3.1 MU2 with the latest patches, we think we are ready to start with compression again.
Beeing experienced on dedup and compressen, I do have a question. We only have experience in converting not replicated VV's. It seems it is an other story when converting synchronous replicated VV's. One must give up replication during the convertion ! The only , most save, convertion procedure seems to be moving all data via VMotion (our environment is all VM's) from not compressed VV's to compressed VV's.
Question for you : Any idea to convert to compressed VV's in a synchronous replicated environment with minimal impact concerning replication , using tunevv. Any well working procedures available?

Page 1 of 2 All times are UTC - 5 hours
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/