Page 2 of 2

Re: Physical Copy speed...

Posted: Fri Mar 07, 2014 11:00 am
by Richard Siemers
I am guessing here, but it sounds like the system may impose some limits on its internal tasks, like cloning (but I assume DO, AO as well), to avoid impacting host operations. Can any of the 3PAR gurus/employees confirm this behavior exists, and if it is tunable?

Re: Physical Copy speed...

Posted: Mon Mar 10, 2014 11:50 am
by Andy
Just wanted to let you all know that the resync and promotion worked. Resync only took a couple of minutes and the promotion was basically instant.

Thanks for all the input...

-Andy

Re: Physical Copy speed...

Posted: Wed Mar 12, 2014 8:25 pm
by Cleanur
You can use createvvcopy -pri high to set a higher priority for an offline copy i.e one you can only export and use once the full copy is complete. I don't remember the numbers but 150MB/s springs to mind for a single VV, also as the number of concurrent copies increases so too does the bandwidth made available to the copy process. The max bandwidth made available is a function of the number of controllers and yes it's intentionally gated so as not to impact front end performance. You can also change the priority afterwards using settask.

I don't fully understand the circumstances of the problem you encountered with VMware, but with 3PAR you can also do an online physical copy using createvvcopy -online. This makes the volume immediately accessible, just like a RW snapshot (in fact it starts with a snap), so users can use the volume whilst the full data copy completes as a background.process. In the online mode copy speed isn't such a concern, it will finish in its own time and the subsequent volume will become independent of the parent.

Greyed out promotes are typically because the volume is exported, it's not made obvious in the GUI but it's a safe guard to stop the Host OS panicking / losing data if you were to suddenly overwrite the data without it's knowledge.

Re: Physical Copy speed...

Posted: Thu Mar 13, 2014 4:07 am
by Cleanur
Just double checked the detail

Physical copy performance is highly dependent on the number of concurrent copy jobs in operation, the priority placed on the copy task, and the available resources within the system.

Default priority 1 parallel 50MB/s
Default priority 4 parallel 200MB/s

High priority 1 parallel 150MB/s
High priority 4 parallel 600MB/s

Up to 2 concurrent physical copies are allowed per node, so a 4 node system can run 8 concurrent copies.

Re: Physical Copy speed...

Posted: Thu Mar 13, 2014 7:48 am
by Andy
Cleanur,
Thanks for the info...my real world experience...a single copy job running was 43 hours for 7.2TB. A little math...that's about 48MB/s...right on with what you posted.
To be honest...7200 owner...no training...IMC is my friend. I wouldn't have even guessed that you can change priority of the task since that does not appear to be exposed in IMC. I've looked over the CLI reference, but it is not written well to focus in on specific tasks. You kind of have to know what you are looking for.

-Andy

Re: Physical Copy speed...

Posted: Thu Mar 13, 2014 10:45 am
by Cleanur
Have a search for the "HP 3PAR Command Line Interface Administrator’s Manual". It has the various CLI commands and switches listed in context with the typical admin actions, rather than just a long alphabetical list as in the CLI reference guide.

Re: Physical Copy speed...

Posted: Fri Mar 14, 2014 11:40 am
by Richard Siemers
So our ESX admin ran into an issue with 3PAR and DRS moving stuff around. We still haven't full resolved the case yet, but its looking like reservation conflict related. ESX is reporting a 50,000 ms latency for the copy, but the array is reporting 5 - 8 ms. A showeventlog -debug shows a ton of reservation conflicts.

We don't have VASA working, were still working through that, so the copy offloading was attempted and failed because it was moving across T800s, then reverted to a ESX based copy. I suspect the issue will lead to one ESX host doing the move, while a separate ESX host is running the VM, and the 2 are playing tug-of-take-a-turn-war with the SCSI locks.