#ARL from FAS2720 to FAS50?

1 messages · Page 1 of 1 (latest)

cerulean moon
#

I have had a look at the guides for ARL and I was not able to find the combination of FAS2720 to FAS50... I realize that this is because the FAS2720 can have internal disks..
I plan to add an empty shelf to the system, just for the controllers, which I would think should solve this issue?
But is it then just plain sailing? 😉

Another task is that we need to replace the disks as well, so we need to configure allow for root aggregates on the new DS460C shelf we want to migrate to. Are there any guides on how to do this? I think I have dont this before, but not often enough that I can remember how 😉

If everything else fails, we do have a set of older NetApp Cluster switches that we could use (CN1610) and I know it's not supported, but it should work right? Even with only 10G cluster links to the FAS50s ?

I was just thinking that ARL might be the faster way to migrate all the data because we do not need to push the data via the cluster switches... ?

Suggestions are welcome 😉

atomic junco
#

so your FAS2720 has internal disks, right? I don't think you can non-disruptively swap controllers in this case, as you'd need to convert the 2720 to a shelf

cerulean moon
#

We can do with a little disruption... as mentioned I will add the controllers to an empty shelf... 🙂

#

So you are basically telling me that I could just shutdown the old system, recable everything to the FAS50, boot into maint and reassign the disks and boot "normally" ? 😉

atomic junco
cerulean moon
#

Just like the good old days with 7mode 😉 I think this is the way 🙂

#

Now the FAS2720 is actually a FAS2620 with one node which we will have to headswap to FAS2720 and make it HA... we have avaliable Root-partitions for a new root aggr for the new node... they are assigned to the one node right now. Should I just unassign them and boot the new node into maint and choose 4 to init the disks? Or should I first assign the partitions to the node and then choose 4 ?

atomic junco
#

I would assign them first, that way you can make sure that it uses only those disks/partitions and not some other spares

cobalt crag
#

If there is enough capacity on the fas50, build a net new switchless cluster. Set up cluster peering. Use SVM Mobility and move the NAS SVM(s) to the new unit. When the 2720 is clear, do a wipe (option 9a on both), replace controllers with Iom12B and add to new cluster

cobalt crag
#

Another of the wall idea
Add that shelf to the fas2720. Migrate EVERYTHING to the external shelf. Including root aggregates. If all aggregates are external, you should be able to do a manual head swap without downtime.

atomic junco
cerulean moon
cerulean moon
# cobalt crag If there is enough capacity on the fas50, build a net new switchless cluster. Se...

This is actually already snapmirror destination for a lot of volumes and SVMs... isn't it a lot of work to "fix" this? This is basically why I feel the headswap would be better to perserve the cluster peers and snapmirror relations etc.. although the primary system will be "migrated" from a normal HA to a MCCIP where there isn't really any migrationpath other than snapmirror... so we will have to resync the mirrors from the MCCIP....

cerulean moon
# atomic junco this gets complicated though due to manual disk partitioning required

I do have an "internal" paper explaining how to manually create partitions if you do not have any disks to "copy" from like you can do now... you will have to know the size values for the root partition and I guess the other two are just half of whats left... anyway I will of cause try not to use this, and I will look at the factory new F50 partitions.... because I will have to do the "system node migrate-root" (i think it is) where I need to point to partitions that it should use... I think the best bet would be to boot the new F50 into maint mode and remove mailbox disks and delete the root aggregate... then bring up the F50 on the old disks... add the new shelf and assign the partitions and run the migrate-root script... ? makes sense in my head... I am aware that just adding the new shelfs with a valid root aggregate assigned to the F50 systemid will cause issues... maybe not right away, but at boot 😉

cobalt crag
#

Actually....

#

I have been working with a friend of mine.
I would use only 60 of the drives externally. Then through a cool method....migrate both roots to the DS460 shelf with ADP. Then create new aggregates on the DS460, migrate volumes then delete any aggrs on the internal drives

#

Data Mobility (SVM migration) will move and keep any other SnapMirror relationships. You create the cluster peers it does most of the rest

atomic junco
#

you still end up with "ugly" (IMHO) RAID groups on the DS460 shelf if you put the root aggr there...

cobalt crag
#

Nah. 60 drives:
Aggr1 = 28 drives (partitioned)
Aggr2 = 28 drives (partitioned)
4 spares

#

do it all too frequently

#

Or

#

Aggr1 = RG0 - 14 drives (partitioned) + RG1 - 14 Whole
Aggr2 = RG0 - 14 drives (partitioned) + RG1 - 14 Whole

cerulean moon
#

Another quick one... if we were to go another path and add a cluster switch (CN1610) and join teh FAS50 to the exising cluster, can the FAS50 use the 10/25G NICs for cluster or does it have to use the 100G NICs? Or will I have to use some Nexus's with can do 100G ?

atomic junco
#

I would still go with the "shutdown, recable, reassign disks, boot" method as it is the quickest in total time required.
As for your last question, you can (technically) use arbitrary ports for the cluster network, even 10gig ones, but it won't be supported (which is fine if it's for temporary migration purposes only). You do need the proper ports for the HA cabling though, that is not optional and not switchable

cobalt crag
# cerulean moon Another quick one... if we were to go another path and add a cluster switch (CN1...

There’s definitely more to it. I think temporary you might. However since the new fas units send both ha and cluster over the same interface and ha require priority flow control (with isn’t available on the 1610) you ultimately need to do through the hassle of going through the process to temporally split cluster away from HA. You can run cluster on most other network ports but in your case you would need 10g. Then when you are done, you would need to combine them back.

There is a kb about it but I’m pretty sure it’s buried for customers and only exposes commands to support and partners

#

If you can take the down time, as suggested, just reenable. There is a method in the hardware upgrade guide on this scenario (migrating from in chassis disks to external) which does the shutdown/re-cable/fix network process

cerulean moon
#

Seems like the 10/25G links can be used in a switched setup

image.png
#

Not sure if the priority flow control make a difference? We will of cause be moving all data over the switches after all 🙂 The reason we might be considering this is the few unknowns with the re-cable approach... there was some possible issues if the HA ports collide? Not sure if it's an issue because FAS2700 used e0a+b and FAS50 used e4a+b ?

cobalt crag
#

Yes and no.

PFC is for the HA connections.

If PFC is not available, HA will not work. (You can test this by mis-cabling a switched cluster: put node 1 on switch one-both ports and node 2 on switch two-both ports, HA will not engage until the "a" and "b" ports can talk with each other, plus look at the RCF, the HA VLAN does not pass through the ISL)
Here is the thing, the chart you are showing, which I also pulled up in HWU does not specify the CN1610 (which DOES NOT support PFC , priority Flow Control). It does list all the current switches (BES, NEXUS) -> which, if using a supported RCF, enabled PFC on every downstream port)

Like I said, You may be able to use the CN1610, but the HA will stay locally connected:
e4a <-> e4a and e4b <-> e4b
You would need to use the KB to break the "cluster" ports away from e4a/e4b and no, it is NOT just creating new ports and adding them (because the new ports will want the HA enabled)

#

You would still need at least 2 x 10G ports to connect through the 1610. Even then, it is not a supported config.

#

The shutdown method or SVM Mobilty are you best choices here

atomic junco
#

if you want to get fancy, you can connect one port directly to the HA partner and one port to the switch. Then HA will work without redundancy over the first link, while cluster network will also work (also without redundancy) over the second link 🤪 I guess we can come up with more weird "solutions" if you give us time, but I would suggest to just use one of the methods TMAC mentioned and not think too hard about it 🙂

cobalt crag
#

In that case @atomic junco , pretty sure it will stay a switchless cluster

#

Pretty sure that both ports must have "full-mesh" for switchless cluster to flip to false

atomic junco
#

again, no suggestions, just brainstorming, don't get us wrong @cerulean moon 😉

cobalt crag
#

One of those things -> just dont do it unless you dont care skeptical

cerulean moon
#

...and about the "collision" of the HA ports, should I worry or am I in the clear with the F50 ports on e4a+b ?

cobalt crag
#

It’s standard/normal on all new platforms. Historically the HA was internal. On all new platforms it’s typically on the same shared network with cluster. If you’re inclined look at the Cisco rcf and look at the port definitions and then look what’s allowed over the port channel/isl.

Just be sure to plug e4a to e4a and e4b to e4b

sonic breach
cerulean moon
#

OK, so today I manage to get this process done, but not without issues... The swap from FAS2620 Singlenode-cluster to FAS2720 was pretty easy, basically just a "mailbox destroy local" (even though I don't even think a singlenode-cluster uses mailbox?) Adding the 2nd node to the cluster was a bit worse because it was not able to create the aggr0 when booted into menu and init the disks... I had 8 P2 partitions at the same size as the first node... so first I tried to just assign them to the new node and init them... but this failed for some reason.. I then tried to make the partitions unknowned... and then it did identify them, and assigned 3 of them, rebooted but then again failed most likely because just three of them wasn't large enough... luckly I managed to assign three full disks, and then it build a new aggr0 on the full disks... (we will change this later do don't matter)... of cause I configured the ha-config for chassis and controller to HA on both nodes... but the HA failover was not working... it complained about the original node beeing in "non-ha" mode... I checked the ha-config and it was OK... after a bit of digging I found out there is an option "storage failover modify -mode ... which was set to "non_ha".. after setting this to ha, we where good 🙂 And another thing was that I had to anually add e0a+e0b to the Cluster broadcast domain.. and create two cluster lifs... but all in all I got it working as a cluster... then way too many updates in order to get from 9.11 to 9.16... then swap to the F50 and finally attach the new disks.... pew.. that was a whole days work 🙂 again mostly waiting for the controllers to boot, and ontap updates... 🙂 but the non_ha thing almost defeated me... and for some reason the process from a singlenode-clustre to ha isn't really documented anywhere, or at least I didn't find it... 🙂

#

Thanks for all your feedback 🙂

atomic junco
#

and for some reason the process from a singlenode-clustre to ha isn't really documented anywhere, or at least I didn't find it...
Probably because single-node clusters haven't been supported in ages 😉

cerulean moon
exotic sequoia
#

I think we still have a customer running their 7-mode fabric metro 🙈