Personally, since the 6080 is supported all the way to 8.2, I wouldupgrade them to the same release as your 6290s.
The upgrade doesn't really affect anything other than vol0 does it? Since the new hardware already has new root aggregates and vol0s that are at the OS rev I want, upgrading the existing vol0 disks seems an unneeded step.
I know there will be new disk and shelf firmware, but I wanted to let those update during the outage window just in case something happened.
If possible, I try and make the source and destination the sameSave the headaches of significant multiple changes at once.
or as close to the same as possible.
I was hoping skipping the OS upgrade of the root drives was going to be one less significant change :-)
(like local mailbox, making sure the right heads get the right disks, etc)Do you have ha? Other concerns there too if you do
We do have HA. Both new 7-mode clusters are already configured. They should have their mailbox drives defined with the new disk shelves. I do have the system IDs of all the old and new heads. We should be able to do the disk reassign in maintenance mode once the outage window is available.
Am I still missing something about importing the aggregates to the new heads once the system IDs are reassigned?
Thanks,
Jeff
--tmacTim McCarthyPrincipal Consultant
Clustered ONTAP Clustered ONTAPNCDA ID: XK7R3GEKC1QQ2LVD RHCE5 805007643429572 NCSIE ID: C14QPHE21FR4YWD4Expires: 08 November 2014 Expires w/release of RHEL7 Expires: 08 November 2014On Wed, Jun 26, 2013 at 12:25 PM, Jeff Cleverley <jeff.cleverley@avagotech.com> wrote:
_______________________________________________Greetings,
I think I have a good handle on what I need to do but wanted to check for additional gotchas. We've got some 6290s that will replace some 6080. The 6290s are already built with their own root volume/disks and are running 8.1.2P4. The 6080s are running 7.3.5.1P4. I'm not planning on using the 6080 root disks so I'm not planning on upgrading the 6080s before hand. The plan is basically shut everything down, pull the 7.3.5 root disks, reassign all the other disks to the new system IDs and boot everything up.
It is my understanding that there is no 64 bit upgrade to aggregates/volumes that gets done automatically so I'm not seeing and issue there. I have functional /etc/rc, exports, hosts, and username.map files in place on the new hardware. I'm also going to have a copy of the old /etc directories on the new filers so I'll have everything there if I need to go back to them. All needed hardware is in the new heads and supported.
The new hardware has newer disk and shelf firmware but I'm going to let it do that during boot up. We have some MOOS drives that have been problematic so I don't want to do those before hand. We have no VM, very little cifs, and 1 SAN/FCP client. Other than that it is all nfs clients. I know I may or may not have to re-join the domain for the cifs piece but I can deal with that.
It seems this should be relatively simple and easy, but that's usually when I get into trouble :-) Any obvious holes/flaws in my plans that I should be aware of?
Thanks,
Jeff
--
Jeff Cleverley
Unix Systems Administrator
4380 Ziegler Road
Fort Collins, Colorado 80525
970-288-4611
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters
