Physical Copy speed...

User avatar
Richard Siemers
Site Admin
Posts: 1333
Joined: Tue Aug 18, 2009 10:35 pm
Location: Dallas, Texas

Re: Physical Copy speed...

Post 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?
Richard Siemers
The views and opinions expressed are my own and do not necessarily reflect those of my employer.
Andy
Posts: 13
Joined: Wed Mar 05, 2014 11:23 am

Re: Physical Copy speed...

Post 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
Cleanur
Posts: 254
Joined: Wed Aug 07, 2013 3:22 pm

Re: Physical Copy speed...

Post 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.
Last edited by Cleanur on Thu Mar 13, 2014 4:10 am, edited 2 times in total.
Cleanur
Posts: 254
Joined: Wed Aug 07, 2013 3:22 pm

Re: Physical Copy speed...

Post 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.
Andy
Posts: 13
Joined: Wed Mar 05, 2014 11:23 am

Re: Physical Copy speed...

Post 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
Cleanur
Posts: 254
Joined: Wed Aug 07, 2013 3:22 pm

Re: Physical Copy speed...

Post 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.
User avatar
Richard Siemers
Site Admin
Posts: 1333
Joined: Tue Aug 18, 2009 10:35 pm
Location: Dallas, Texas

Re: Physical Copy speed...

Post 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.
Richard Siemers
The views and opinions expressed are my own and do not necessarily reflect those of my employer.
Post Reply