ONTAP Hardware

Physically moving an aggregate composed of disks

midi
6,378 Views

Hello,

 

we have a FAS8040 with two DS4486 shelves, Ontap 9.1P11 and a FAS8060 Ontap 9.1P11.

We want to remove these two shelves with existing aggregates and datas, and then add to FAS8060, is the below kb OK for that, or we should do more than that?

 

https://library.netapp.com/ecmdocs/ECMP1196986/html/GUID-85C8CF29-1FF6-4DC1-9835-EB89E7EA1BF6.html

 

 

Regards,

1 ACCEPTED SOLUTION

AlexDawson
6,291 Views

Yes, I understand your question. It is not as simple as it was on 7-mode systems.

 

It is only possible to do by NetApp PS staff - those resources are to help them, if you engage them. 

View solution in original post

9 REPLIES 9

AlexDawson
6,305 Views

Hi there,

 

Unfortunately this is not part of core ONTAP functionality. We are tracking this as a request for future functionality enhacement in RFE BURT 814304

 

It is not impossible to do it with current tools, but it should only be done by NetApp Professional Services and it is a very involved task which risks data integrity - for NetApp Staff, please refer to case 2005538876 for details.

 

Please contact your local account team to engage them

midi
6,298 Views

Hi Alex,

 

Thanks for your reply,

I could not reach the case and the bug details, it looks "bug info not available", can you share the details about the bug and case.

 

By the way, I physically moved aggregates composed of disk for another customer has 7-mode systems. I mean we did this before for 7-mode systems.

What we try to learn is that is it possible to move aggragtes physically from c-mode to c-mode. 

 

Regards.

AlexDawson
6,292 Views

Yes, I understand your question. It is not as simple as it was on 7-mode systems.

 

It is only possible to do by NetApp PS staff - those resources are to help them, if you engage them. 

aleex
6,203 Views

Hello,

 

we've done this in our cluster a few weeks ago.

 

It is very dangerous if you do not really know, what you are doing - so do it own your own risk 🙂

Details can be read in my blog post about this move: 

 

https://blog.krogloth.de/moving-aggregate-within-a-cdot-cluster-from-von-ha-pair-to-another/

 

Good luck and best regards,

Alex

AlexDawson
6,191 Views

Well done 🙂

 

Was this from one HA pair within a cluster to another HA pair in the same cluster? I can see that would probably be pretty clean, since the volume UUIDs would remap them into the same SVM they were in previously.

 

In the scenario where they are moved between clusters, there is an additional need to rehost volumes to a new SVM, re-create export policies, access controls, etc., and that creates risks of allowing access where it shouldn't, loss of ACLs and probably many other things.

aleex
5,987 Views

It was inside a cDOT cluster.

 

There were only DP volumes left on this aggregate - otherwise I wouldn't have done this 🙂

SeanHatfield
6,166 Views

Very nice.  For bonus points, do it non-disruptively. Smiley Happy

If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.

AlexDawson
6,163 Views

Smiley Surprised

D_BEREZENKO
5,853 Views

Also, you might consider Copying approach with SMTape functionality, which can backup your volumes to tape. In this kind of scenario, you can copy data to tape, then destroy aggregates on FAS8040 to release disks from DS4486, detach DS4486 with disks, re-cable DS with empty disks it to FAS8060, create new aggregates and new empty FlexVols, and finally restore data from tape to that volumes.

 

Alternatively, you can combine my answer with Alex's answer just in case if things go wrong.

Public