General guidelines on upgrading AFF controllers

[whole oasis]

If I plan to upgrade A300 to A400 controllers, is the following document a general guideline on how? If yes, how come the document only mentioned about migrating none-root aggregates. Can somebody please point out to me where can I find the guidelines on how to migrate root aggregates, or I have to create new ones?
https://docs.netapp.com/us-en/ontap-systems-upgrade/upgrade-arl-auto-app/index.html

[old cedar]

This page covers moving the root aggregates - https://docs.netapp.com/us-en/ontap-systems-upgrade/upgrade-arl-auto/set_fc_or_uta_uta2_config_on_node3.html - basically once you've turned off node 1 out, you tell node 3 to destroy it's root aggregate and use node 1's instead.

[whole oasis]

What I feel weird about the page you pointed out is that moving the root aggregates is stated only n the section of "Check and configure UTA/UTA2 ports on node3", whereas here we only have NAS and don't have FC, or UTA/UTA2. Also it used FAS8080 as an example, whereas here we have AFF here which should be alright because it may apply both FAS and AFF. But, as a guidelines on "moving root aggr" as important part , it is only mentioned in FC UTA/UTA2 section, that makes me wonder if we are missing something?

[whole oasis]

Can experts here please shed some light on my questions? Did they make sense to you?

[old cedar]

I agrée with you that it’s an odd page to have it on. @sonic cloud and @stray solstice have probably done more of them than I ever will. Can you confirm or correct what I’ve said above?

[sonic cloud]

Well, actually if you're doing an ARL-based upgrade, the new hardware doesn't have any storage associated with it so there's no root aggr (on the A400) to be concerned with.

In the referenced documentation, it talks about moving non-root aggrs back and forth between nodes, this is part of NDU, so there is no need to move root aggrs, they simply get ingested (wrong choice of word, but I can't think of another) by the new node for its own use.

During the upgrade, make sure you're logging the console as you may need to scroll back at one point. Last time I did this, there was a point where the operator was prompted for input, but then the screen was spammed with output and if you weren't paying attention, you wouldn't have seen the question. I think the question was around NSE drives and if you answer incorrectly, then you start to get weird error messages about not recognizing any drives...assuming you answered the wrong way of the drives you have, NSE or non.

[whole oasis]

@sonic cloud "ingested" -- Somehow the A400 controller is able to inherit root AGGR and put it under it's control?

[sonic cloud]

Yes, here's an excerpt from a logfile I captured while upgrading an AFF 8080 an an A400:

Jan 19 22:01:45 [localhost:raid.assim.tree.foreign:error]: raidtree_verify: Aggregate mroot_n1 is a foreign aggregate and is being taken offline. Use the 'storage aggregate online' command to bring it online.
There appears to be a consistent set of aggregates
Jan 19 22:01:45 [localhost:raid.assim.tree.noRootVol:error]: No usable root volume was found!
for a system with an NVRAM board other than the one in this system.  NVRAM
contents will be discarded and the disks will be labeled with the serial
Jan 19 22:01:45 [localhost:raid.assim.label.noNativeVols:notice]: No native volumes or aggregates detected, assuming NVRAM card swap. 1 NVRAM system id(s) (537019586, 0, 0...) found among all volumes. NVRAM system id 537019586 selected. NVRAM card swap detected by RAID.
number of this system's NVRAM board.
Jan 19 22:01:45 [localhost:raid.assim.label.makeNativeVol:notice]: Aggregate mroot_n1 turned into a native aggregate.```

Once you run the system controller replace start command, it's mostly automatic from there.

On the partner node you can run system controller replace show or better yet system controller replace show-details

With most upgrades, most of the work is in the prep work...The more you do, the easier the upgrade itself will be. Most problems arise from network port mismatches.

[old cedar]

Thanks Chris! Legendary as always

With this in mind, do you think we should make the documentation clearer?

[whole oasis]

I wish the document should mention that and fill the puzzle since how root AGGR gets to the new HA is an important part which was not clear to me.

@sonic cloud You cleared up the confusion and for other infor, Thanks!

[sonic cloud]

You should see the novel I wrote to doccomments@ last year around the ARL documentation, in short, yes.

[sonic cloud]

Documentation typically address the "how" and not the "why", if you follow it blindly and nothing goes wrong, it should accomplish the task. Right or wrong, that's how it is.

I'm glad I could help though.

[azure viper]

If I recall it correctly you can do ctrl+r to get the last question and your current inputs printed again. Works well if your screen is spammed or you switched your serial cable across nodes to see where you actually are

[grave compass]

Between your novel and my dissertation, I think Netapp ended up with new documents for the process!

[whole oasis]

Can you please share the new document for the process?

[drowsy quail]

I wish the document should mention that and fill the puzzle since how root AGGR gets to the new HA is an important part which was not clear to me.
Are you adding the new pair and then retiring the old pair or doing an in-place upgrade? If so, that's a different upgrade and you don't migrate the root aggregate - you create a new root aggregate and create new root volumes as an LS member of your original vol0.

[whole oasis]

@drowsy quail We are doing 2-heads swap, may be in-place upgrade in your term? create a new root aggr on where? the 2-old A300 already have root aggrs.