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

Change Raid Level - path
https://3parug.com/viewtopic.php?f=18&t=3027
Page 1 of 1

Author:  skumflum [ Thu Nov 01, 2018 9:11 am ]
Post subject:  Change Raid Level - path

I want to change the RAID level to R6 (14+2).

My system is a 3par 8400 4-node with 64 SSD Drives (76% full)
My initial plan was to either change the current CPG and run tunesys or create new CPG and tunevv.
I wanted to try out tunevv at first but ran into problems.
Oct 30, 2018 3:51:37 PM CET 2FF70002AC01C8CE : error: VV prd.dc1esxcomp1-01.tdvv has dedup accounting in process.
Oct 30, 2018 3:51:37 PM CET Failed: 2FF70002AC01C8CE : error: VV prd.dc1esxcomp1-01.tdvv has dedup accounting in process

I open a support case with HPE. He explained that I can’t run tunevv due to Garbage Collector. If I want to tunevv to another CPG I have to: disable gc -> tunevv -> enable gc --- then wait for GC to complete. However, this can only be disabled by HPE support team ☹

He strongly recommended against changing the current CPGs and running tunesys. I could risk severe performance degradation.

The only option that he would recommend is to do the migration on the host (Storage vMotion to new volumes).


What is your take on this? I am stunned… all the fancy stuff that I thought I could do on the 3PAR system is in rubble

Author:  ailean [ Thu Nov 01, 2018 10:05 am ]
Post subject:  Re: Change Raid Level - path

I've heard a few limits on dedup volumes in the past, normally more issues on 2 node systems as resources limit for doing stuff with GC running.

I turned off our dedup on our 8400s as small boxes with mostly DBs so dedup return was tiny (then converted from R1 to R5 to get more space) but I'll be playing more with our new 9000s as much larger and mixed use.


Which OS and dedup version are you on, latest is meant to be less resource hungry and better design so hopefully more flexible.

Author:  MammaGutt [ Thu Nov 01, 2018 12:45 pm ]
Post subject:  Re: Change Raid Level - path

8400 with that many SSDs could become interessting with tunesys.

As long as you're just doing dedupe I wouldn't discard the tunesys option quite yet...

You could create new CPG, but remember that the DDS isn't reclaimed from the old CPG before the last dedupe volume is gone.

If I were in your shoes I would try the tunesys option. If you start getting severe latency, just cancel tunesys and you're back to normal within a very short time. If it becomes an issue you could tune individual LDs in service windows where you can accept increased latency.

Author:  skumflum [ Thu Nov 01, 2018 5:55 pm ]
Post subject:  Re: Change Raid Level - path

MammaGutt wrote:
8400 with that many SSDs could become interessting with tunesys.

As long as you're just doing dedupe I wouldn't discard the tunesys option quite yet...

You could create new CPG, but remember that the DDS isn't reclaimed from the old CPG before the last dedupe volume is gone.

If I were in your shoes I would try the tunesys option. If you start getting severe latency, just cancel tunesys and you're back to normal within a very short time. If it becomes an issue you could tune individual LDs in service windows where you can accept increased latency.


What do you mean with "tunesys could become interesting?" :)

I don't use compressed volumes. I have many dedup volumes created under 3.2.1/3.2.2 OS. If i tunesys the system, will it convert it du dedup v3?

What about space reclemation during tunesys? Could I risk that the system will run full?

Author:  markinnz [ Thu Nov 01, 2018 8:17 pm ]
Post subject:  Re: Change Raid Level - path

I had a similar exercise to do when we 1st got our 8400s, De-dupe was borked and caused high latency and then after support disabled GC we had array crashes. All down to code bugs, but to get out of de-dupe we had to do the following :

1) Create a new CPG
2) Go from de-dupe volumes to thin volumes and tunevv them into the new CPG
- just a few volumes at a time and let the array garbage colection process cleanup and shrink the de-dupe database/store/volume/LD in the background

If you have enough free space to go from de-dupe to thin then you could skip the waiting for garbage colleciton part, once the old CPG has no voumes associated with it you can delete it and the de-dupe store gets deleted in one go, you'd get the space back pretty quick.

Author:  MammaGutt [ Fri Nov 02, 2018 2:59 am ]
Post subject:  Re: Change Raid Level - path

skumflum wrote:
MammaGutt wrote:
8400 with that many SSDs could become interessting with tunesys.

As long as you're just doing dedupe I wouldn't discard the tunesys option quite yet...

You could create new CPG, but remember that the DDS isn't reclaimed from the old CPG before the last dedupe volume is gone.

If I were in your shoes I would try the tunesys option. If you start getting severe latency, just cancel tunesys and you're back to normal within a very short time. If it becomes an issue you could tune individual LDs in service windows where you can accept increased latency.


What do you mean with "tunesys could become interesting?" :)

I don't use compressed volumes. I have many dedup volumes created under 3.2.1/3.2.2 OS. If i tunesys the system, will it convert it du dedup v3?

What about space reclemation during tunesys? Could I risk that the system will run full?


What I mean is that the controllers might become a bottleneck when tuneld kicks in and you could see an increase in latency.

Author:  Proc_rqrd [ Fri Nov 02, 2018 9:48 am ]
Post subject:  Re: Change Raid Level - path

your first two options are feasible, but again can be an issue with the amount of free space you have. if your using dedupe, whats you ratio? a high ratio will work against you being at 76% used. svmotion was recommended, i believe, to give you the safest with least system impact.

with either tunevv or tunesys id disable garbage collection until your done if you choose those options. once complete and on R6SS14, you can turn it back on, run more tunesys/compacts see where you are.

are you moving to R6SS14 to make more space available? i guess id do svmotion if it was all vm volumes in that CPG.

Author:  skumflum [ Thu Jan 17, 2019 2:41 am ]
Post subject:  Re: Change Raid Level - path

sorry for the late reply.

I am going for host based migration. However, I am worried about free space - do I have enough.

As I understand it the Dedup DDS “partition” won’t be reclaimed before the last VV is deleted from the CPG?

I have attached screenshot from showvv -s. Can this tell me anything about how much free RAW space that I need?

Attachments:
2019-01-17_08-27-54.png
2019-01-17_08-27-54.png [ 130.84 KiB | Viewed 19386 times ]

Author:  MammaGutt [ Thu Jan 17, 2019 3:20 am ]
Post subject:  Re: Change Raid Level - path

If those two volumes are all volumes in TDVVs CPG and you are tuning to TPVV in R6 (14+2) you need the capacity of hostwr * RAID overhead in RAW capacity. That would be approx 3.6 TB * 12.5% overhead if my memory serves me right. That will be just over 4TB RAW.

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