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

3PAR OS 3.3.1 MU1 is released
https://3parug.com/viewtopic.php?f=18&t=2462
Page 4 of 19

Author:  mitchellm3 [ Mon Jun 12, 2017 9:36 pm ]
Post subject:  Re: 3PAR OS 3.3.1 is GA

Are you running 8200/8400's or 8440/8450's?

Back when we tried some small 7200's with SSD and dedupe for our VDI environment, they would just crawl when AV updates were written. Randomizing them helped but...you shouldn't have to randomize your AV definitions to make your AFA perform as promised. HPE said the dedupe was a CPU process the 7200 was short on cores. They swapped them out with 7450's and that worked great.

We are getting a new 8440 prepped for the 3.3.1 install and as of right now I'm planning on using compression for just about every VV. So what are you using?

Author:  Chris212 [ Tue Jun 13, 2017 2:18 am ]
Post subject:  Re: 3PAR OS 3.3.1 is GA

As you can see on my previous posts, we are running two 8200 nodes.
Dedupe is an ASICS process, compression apparently is a CPU process.

8440 should be fine as you have 10-core CPU instead of 6 for a 8200 and you still have 2 more nodes with more cpu if you start running low with them.

We did not see this cpu utilization with our test, until we migrate our 400 vm's on our 8200 nodes (200 vm each side with peer persistence) .
All of our VV are compressed and standard vm's are dedupe. Only database VM's have compression only.

Do you have 2 nodes 8440 or 4-nodes ? How many VM's will you migrate ?

Author:  mitchellm3 [ Tue Jun 13, 2017 8:28 am ]
Post subject:  Re: 3PAR OS 3.3.1 is GA

We went with the 4 node 8440's with 64 3.84T SSD drives. Our plan is to move ~300 VMs. Something else we are looking at is moving the environment to ESXi 6.5 so we can use VMFS6 datastores. With VMFS6, unmap is added back but it is supposed to be more measured and won't unmap the entire datastore at once. Are you using VMFS6 datastores with the unmap turned on?

Author:  Chris212 [ Wed Jun 14, 2017 3:03 am ]
Post subject:  Re: 3PAR OS 3.3.1 is GA

Nop, we are on vsphere 6.0 therefore VMFS6 is not available.
But i think it is a good idea to upgrade the environment before migration. Auto unmap is certainly a great improvement with 3par.

Author:  mitchellm3 [ Mon Jun 26, 2017 2:01 pm ]
Post subject:  Re: 3PAR OS 3.3.1 is GA

After having a chat with HPE last week it seems they are closing down the "controlled release" program...or at least are limiting the restrictions to get in the program because they feel pretty confident with the existing deployment base that things are looking good.

Last Thursday I was able to download 3.3.1 and P02. Today I can download SP 4.5 w/ P01 but they removed the 3.3.1 links. I'm still waiting for them to schedule the install and I don't plan on installing it on my own...though I might if they don't hurry up...but it seems that since they are posting code they might make it GA soon.

Author:  cla@atea.dk [ Wed Jul 05, 2017 5:09 am ]
Post subject:  Re: 3PAR OS 3.3.1 is GA

Hi

Downloaded the 3.3.1 including P1 and P2.
Also got the SP 4.5 with p1 and the SP 5.0

Remember the SP4.5 is an interim upgrade version that can't be used for other than upgradíng the SP to 5.0. The SP5.0 changes the entire OS so be aware.
Also the users are chainging from the old 3parcust, spvar and spdood, to newer users called "Admin, Hpepartner and hpesupport". i dont have the password for the "Hpepartner" but trying to get it.
Apperently the "Admin" (old 3parcust) seems to be downgrated on rights and cannot run stuff like upgrades and admithw anymore.

Also the new SP5.0 changes the VM requirements so that you now need 4 CPU, 2 cores and two sockets. And 4GB of memory.

The new 9450 ships with the 3.3.1 as default and as i'm told they should start to ship them around now.

Author:  mitchellm3 [ Thu Jul 06, 2017 3:51 pm ]
Post subject:  Re: 3PAR OS 3.3.1 is GA

We've been running 3.3.1 for almost a week now. We have migrated around 300 VMs. So far the data reduction is sitting at 2.3:1 without having optimized VMs with 16k blocks. Looking at the CPU utilization it is noticeably higher than our other arrays without compression. The CPU runs between 25-35%...and it isn't a heavily used array.

I did not get to use VMFS6 with this migration because we could not go to 6.5 due to some bugs that aren't fixed until update 1...but those aren't 3par specific issues. Support on the old array ended June 30 so we were anxious to move off of it.

I did get to test the storage vmotion on the array from one datastore to another. Using statvv, you can see the IOps and throughput crank way up. It does introduce much higher latency than normal but I'm not sure how noticeable it will be to the VMs. As far as speed is concerned...it seems much faster than previous versions but I don't have any side by side testing so its just going off my impressions. It would be great to see what others have noticed in the SVMotion area.

Author:  cbuxton [ Tue Jul 18, 2017 4:04 pm ]
Post subject:  Re: 3PAR OS 3.3.1 is GA

cla@atea.dk wrote:
Downloaded the 3.3.1 including P1 and P2.
Also got the SP 4.5 with p1 and the SP 5.0


Anybody else NOT seeing the downloads? I saw 3.3.1 EGA and downloaded it a while back, then found the SP 4.5 P01, but I do not see SP 5.0, nor anything related to 3.3.1 anymore.

Author:  Reactor [ Tue Jul 18, 2017 11:58 pm ]
Post subject:  Re: 3PAR OS 3.3.1 is GA

I never did see SP-5.0, but I, too, managed to grab OS-3.3.1 EGA along with P01 and P02 before they were removed.

I wish I knew the rationale for removing the downloads from the repository—possibly some heretofore unknown bugs in the release, or perhaps an overly-eager engineer posted the update prematurely. It is certainly not the first time I have seen this behaviour.

Author:  rbird97 [ Wed Jul 19, 2017 10:18 am ]
Post subject:  Re: 3PAR OS 3.3.1 is GA

Reactor wrote:
I never did see SP-5.0, but I, too, managed to grab OS-3.3.1 EGA along with P01 and P02 before they were removed.

I wish I knew the rationale for removing the downloads from the repository—possibly some heretofore unknown bugs in the release, or perhaps an overly-eager engineer posted the update prematurely. It is certainly not the first time I have seen this behaviour.



It is a bug. Had my sales guys look into it and it was pulled because of a bug. What that bug was they wouldn't say or they don't know but I guess it is something serious probably in randomly rebooting a node serious

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