Unsolved
This post is more than 5 years old
77 Posts
0
1651
Symmetrix VMAX performance when cloning
Hi,
By this discussion, i want to validate the best practice to establish when cloning a large amount of data in a Symmetrix VMAX40K.
Here's the scenario:
An Oracle DB has 15TB, located in Disk_Group_1 (SATA)
This DB is once in a while, cloned completly to another sets of luns, that are too in DG_1 (SATA).
--> The customer mentionned, that the first time they did this cloning operation, there was a significant slowdown at the disks level, probably because the DB admin went a bit too hard when he initiated he's clone.
I'm thinking that having both the CLONE_SOURCE and CLONE_TARGET in the same Disk_Group might not be the best way to proceed. I'm interested in what way some of your might proceed.
N.B: There is 3 tier in this box: EFD, SAS10K and SATA
Thank you,
Christian
Quincy561
1.3K Posts
1
July 11th, 2014 12:00
In general, I am not a fan of segregating clone targets from the source devices. It generally will result in lower overall performance. However putting the clone targets on separate disks can reduce the impact on the source devices, as long as there are plenty of target disks to handle the load.
Why is the DB on SATA to begin with? With three tiers, shouldn't FAST VP be in play?
Quincy561
1.3K Posts
1
July 11th, 2014 12:00
I would assume each drive can handle 50 IOPs with reasonable response times for SATA. Each write that can't be optimized (sequential) creates 6 disk operations. So 112 drives times 50 IOPs / 6 operations gave me 1000 IOPs. 5,600 IOPs if they are all reads.
CarC8
77 Posts
0
July 11th, 2014 12:00
Ok, i see.
Yes, the SATA drives are in RAID 6. I'm curious on how you obtain the 1000 IOPs density.
I was thinking between 7k and 10k IOPs for the entire SATA pool.
With those big disks, we get a lot of space, but very low IOPs output, i guess it would have been better to get more disks but with less storage capacity. Something to think about for the future upgrade of this VMAX system.
Thank you,
Christian
CarC8
77 Posts
0
July 11th, 2014 12:00
Hi Quincy,
Sorry, i'm not use to the term "segregating", could you explain a bit more what you mean by "I am not a fan of segregating clone targets from the source devices"
Also, you are quite right about the DB being in SATA, i need to ask questions about that as it doesn't make sense to me either.
At the moment, there is only one pool of SATA (DG1), containing 112 disks (3TB).
Thank you for you input so far,
Christian
Quincy561
1.3K Posts
1
July 11th, 2014 12:00
Segregating, meaning keeping the source and targets on separate disks.
I assume the 3TB drives are RAID6. Those are pretty big drives, and they don't do many IOPs, so your IO density capable on them is really low. Maximum write rate that pool could handle would be around 1,000 IOPs. Not much..
CarC8
77 Posts
0
July 11th, 2014 13:00
Allright, that is definatly a point i'm going to have to discuss with my collegues.
Following all the informations you gave me, it won't take a lot of load in order to stress that pool.
In the exemple of the Oracle DB, it is gonna read it's volume and then copy it's data into the same pool. So if the DB admin is pushing too hard, the stress on the disk will get high in no time.
Thanks again for all the good information and sorry if there was some basic questions
Anonymous User
375 Posts
0
July 11th, 2014 23:00
More spindles=The Better performance, lesser spindles=The Slower performance.
Always look at spindle counts for a drives' IOPS handling capability. You can opt for 600 and 900 GB Disks with 15k or 10k for performance increase and use FAST, you will be rocking.