3PAR OS 3.3.1 MU1 is released

[ben.g]

3.3.1 Patch 01 has been released.

http://h20565.www2.hpe.com/hpsc/doc/pub ... 15994en_us

[Richard Siemers]

After 6 hours of waiting off and on for remote HPe employees to deploy 3.3.1 and patch 1... finally have access to a new 8450... Rest in peace IMC, it won't connect to the new system.

[chris.black]

We just purchased 2 new 8450, has anybody tried 3.3.1 yet? Have been trying to find some more info before we upgrade them and stumbled on this awesome forum!!!

[markinnz]

We just purchased 2 new 8450, has anybody tried 3.3.1 yet? Have been trying to find some more info before we upgrade them and stumbled on this awesome forum!!!

We are letting other people be the guinea pigs for a few months before we deploy it

[chris.black]

we really want to use compression...it seems Richard Siemers got his 8450 upgraded hopefully he can share his experience soon

[Chris212]

We have been upgraded to 3.3.1 for our brand new 8200 (SSD). We have almost finished migration from Lefthand to 3par (vmotion)
4x 16GB Lun's with Dedupe/compression : ~300vm's
2x 16GB Lun's with compression for database servers : ~60 vm's

We have migrated our vm's in Thick Provisionning eager zeroed.

We maybe will have to wait some days or weeks to correctly see what dedup/compression ratio we will have but for now :
Compaction : 7.4:1
Data Reduction : 2.0:1
Compression : 1.6:1
Deduplication : 1.7:1

At beginning we were a bit disappointed to see the dedup ratio but we were able to migrate our entire storage infrastructure (except backup and exchange db's) which represent ~50x2U Lefthand P4500G2 (12 HDD 600GB 15K each) on two 8200 arrays with 8 x 7TB SSD each (R5) and we still have 40% free space left...

Our vm's are not optimized for 3par dedup (allocation unit not set to 16K for example), we do not have VDI. It is only Windows and Unix servers. We have changed our templates to 16K for new servers, we will maybe see some improvements as we renew them.

From the test we have done before migration :
Lefthand HDD -> 3par 3.2.2 SSD : 10 times faster (IOps, MBps, Response time,...)
3par 3.2.2 -> 3.3.1 : 15% faster (IOps, MBps, Response time,...)

[ben.g]

We have been upgraded to 3.3.1 for our brand new 8200 (SSD). We have almost finished migration from Lefthand to 3par (vmotion)
4x 16GB Lun's with Dedupe/compression : ~300vm's
2x 16GB Lun's with compression for database servers : ~60 vm's

We have migrated our vm's in Thick Provisionning eager zeroed.

We maybe will have to wait some days or weeks to correctly see what dedup/compression ratio we will have but for now :
Compaction : 7.4:1
Data Reduction : 2.0:1
Compression : 1.6:1
Deduplication : 1.7:1

At beginning we were a bit disappointed to see the dedup ratio but we were able to migrate our entire storage infrastructure (except backup and exchange db's) which represent ~50x2U Lefthand P4500G2 (12 HDD 600GB 15K each) on two 8200 arrays with 8 x 7TB SSD each (R5) and we still have 40% free space left...

Our vm's are not optimized for 3par dedup (allocation unit not set to 16K for example), we do not have VDI. It is only Windows and Unix servers. We have changed our templates to 16K for new servers, we will maybe see some improvements as we renew them.

From the test we have done before migration :
Lefthand HDD -> 3par 3.2.2 SSD : 10 times faster (IOps, MBps, Response time,...)
3par 3.2.2 -> 3.3.1 : 15% faster (IOps, MBps, Response time,...)

Hi Chris,

Interesting reading. We have a very similar setup albeit at a much smaller scale (2 x P4500G2 --> 1 x 8200 with expansion shelf)

We have also been upgraded to 3.3.1 patch 01.

With regards to the dedupe ratio, my understanding is that the dedupe figures are across the whole CPG, so if you have LUN's in a CPG that are not deduped they will dilute the figures reported.


We haven't migrated many production workloads onto our new 8200 yet but we are also building out a new SQL 2016 HA environment using Availability Groups so we are looking to utilise dedupe on the database LUN's as we will have 2 copies of the data due to the AG's - I know it is not recommended to put DB's on dedupe LUNs but are there any big performance hits or issues that could arise from doing this?

We will be testing as the environment is built but am keen to hear any feedback from other's experiences.

[cali]

I know it is not recommended to put DB's on dedupe LUNs but are there any big performance hits or issues that could arise from doing this?

Use Compression for Databases, this is why it exist.
Dedup did not work on Database.
Check it out by doing a Dedup Estimation Prior to activate it.

Look at the Technical white paper: HPE 3PAR Adaptive Data Reduction
Databases—Most databases do not contain redundant data blocks but do have redundant data within blocks so they can benefit from compression.

[ben.g]

I know it is not recommended to put DB's on dedupe LUNs but are there any big performance hits or issues that could arise from doing this?

Use Compression for Databases, this is why it exist.
Dedup did not work on Database.
Check it out by doing a Dedup Estimation Prior to activate it.

Look at the Technical white paper: HPE 3PAR Adaptive Data Reduction
Databases—Most databases do not contain redundant data blocks but do have redundant data within blocks so they can benefit from compression.

Yes I understand this for individual databases.

My question was geared towards using SQL HA using Always-On Availability Groups, where there are 2 SQL servers each with a copy of the database (primary and secondary replica). Because there are 2 "exact" copies of 1 database, will it benefit from using dedupe?

EMC have a whitepaper on this stating they get 2.0:1 dedupe on the primary/secondary replica DB's - https://www.emc.com/collateral/white-pa ... ive-wp.pdf

And yes, I understand having it all sitting on the same disk kind of negates the redundancy that would be created by using SQL AG's but this is where we are at (limited budget), we have compute redundancy but not disk at this stage.

[Chris212]

Be careful with compression.
We have activated it on all our LUN's and we are seeing the cpu utilization of our controller nodes around 50-80%, often around 70% and triggers informational alert on our storefront for high cpu utilization (70%).

Discussing with our HPE account manager, he told us that compression utilize CPU, not ASICS and should not be activated for LUN's with standard VM's...

Great to know as this is not written anywhere as a best practice...
We have also two performance warning :
Average SSD write service time is higher than expected : 2.2ms
Average host port write service time is higher than expected : 2.2ms

Our account manager told us that a P02 will arrive soon but do not know yet if it will reduce cpu utilization.