3PAR Users Group

A Storage Administrator Community




Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: Change Raid Level - path
PostPosted: Thu Nov 01, 2018 9:11 am 

Joined: Tue Nov 19, 2013 4:38 pm
Posts: 118
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


Top
 Profile  
Reply with quote  
 Post subject: Re: Change Raid Level - path
PostPosted: Thu Nov 01, 2018 10:05 am 

Joined: Wed Nov 09, 2011 12:01 pm
Posts: 305
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: Change Raid Level - path
PostPosted: Thu Nov 01, 2018 12:45 pm 

Joined: Mon Sep 21, 2015 2:11 pm
Posts: 764
Location: Europe
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: Change Raid Level - path
PostPosted: Thu Nov 01, 2018 5:55 pm 

Joined: Tue Nov 19, 2013 4:38 pm
Posts: 118
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?


Top
 Profile  
Reply with quote  
 Post subject: Re: Change Raid Level - path
PostPosted: Thu Nov 01, 2018 8:17 pm 

Joined: Tue Mar 29, 2016 9:32 pm
Posts: 70
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: Change Raid Level - path
PostPosted: Fri Nov 02, 2018 2:59 am 

Joined: Mon Sep 21, 2015 2:11 pm
Posts: 764
Location: Europe
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: Change Raid Level - path
PostPosted: Fri Nov 02, 2018 9:48 am 

Joined: Thu Feb 04, 2016 4:12 pm
Posts: 24
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: Change Raid Level - path
PostPosted: Thu Jan 17, 2019 2:41 am 

Joined: Tue Nov 19, 2013 4:38 pm
Posts: 118
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 552 times ]
Top
 Profile  
Reply with quote  
 Post subject: Re: Change Raid Level - path
PostPosted: Thu Jan 17, 2019 3:20 am 

Joined: Mon Sep 21, 2015 2:11 pm
Posts: 764
Location: Europe
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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 


Who is online

Users browsing this forum: No registered users and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group | DVGFX2 by: Matt