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
Personally, since the 6080 is supported all the way to 8.2, I would upgrade them to the same release as your 6290s.
If possible, I try and make the source and destination the same or as close to the same as possible.
Save the headaches of significant multiple changes at once.
Do you have ha? Other concerns there too if you do (like local mailbox, making sure the right heads get the right disks, etc)
--tmac
*Tim McCarthy* *Principal Consultant*
Clustered ONTAP Clustered ONTAP NCDA ID: XK7R3GEKC1QQ2LVD RHCE5 805007643429572 NCSIE ID: C14QPHE21FR4YWD4 Expires: 08 November 2014 Expires w/release of RHEL7 Expires: 08 November 2014
On 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
On Thu, Jun 27, 2013 at 4:53 AM, tmac tmacmd@gmail.com wrote:
Personally, since the 6080 is supported all the way to 8.2, I would upgrade 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 same or as close to the same as possible.
Save the headaches of significant multiple changes at once.
I was hoping skipping the OS upgrade of the root drives was going to be one less significant change :-)
Do you have ha? Other concerns there too if you do (like local mailbox, making sure the right heads get the right disks, etc)
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
--tmac
*Tim McCarthy* *Principal Consultant*
Clustered ONTAP Clustered ONTAP NCDA ID: XK7R3GEKC1QQ2LVD RHCE5 805007643429572 NCSIE ID: C14QPHE21FR4YWD4 Expires: 08 November 2014 Expires w/release of RHEL7 Expires: 08 November 2014
On 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
You will want to upgrade your disk firmware prior to the upgrade as it upgrades 1 disks at a time and takes 2-3 minutes each disk.
--JMS
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Jeff Cleverley Sent: Thursday, June 27, 2013 11:56 AM To: tmac Cc: Toasters@teaparty.net Subject: Re: Hardware migration process
On Thu, Jun 27, 2013 at 4:53 AM, tmac <tmacmd@gmail.commailto:tmacmd@gmail.com> wrote: Personally, since the 6080 is supported all the way to 8.2, I would upgrade 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 same or as close to the same as possible. Save the headaches of significant multiple changes at once.
I was hoping skipping the OS upgrade of the root drives was going to be one less significant change :-)
Do you have ha? Other concerns there too if you do (like local mailbox, making sure the right heads get the right disks, etc)
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
--tmac
Tim McCarthy Principal Consultant [http://dl.dropbox.com/u/6874230/na_cert_dma_2c.jpg] [http://dl.dropbox.com/u/6874230/rhce.jpeg] [http://dl.dropbox.com/u/6874230/na_cert_ie-san_2c.jpg]
Clustered ONTAP Clustered ONTAP NCDA ID: XK7R3GEKC1QQ2LVD RHCE5 805007643429572 NCSIE ID: C14QPHE21FR4YWD4 Expires: 08 November 2014 Expires w/release of RHEL7 Expires: 08 November 2014
On Wed, Jun 26, 2013 at 12:25 PM, Jeff Cleverley <jeff.cleverley@avagotech.commailto: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-4611tel:970-288-4611 _______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
Unfortunately the main drives that need to have the firmware upgraded are the MOOS drives. That level of firmware is only delivered with the new OS. I was planning on letting it do the firmware upgrades during the outage window after moving the drives to the new hardware that has the correct OS.
Jeff
On Thu, Jun 27, 2013 at 10:01 AM, Jordan Slingerland < Jordan.Slingerland@independenthealth.com> wrote:
You will want to upgrade your disk firmware prior to the upgrade as it upgrades 1 disks at a time and takes 2-3 minutes each disk.****
--JMS****
*From:* toasters-bounces@teaparty.net [mailto: toasters-bounces@teaparty.net] *On Behalf Of *Jeff Cleverley *Sent:* Thursday, June 27, 2013 11:56 AM *To:* tmac *Cc:* Toasters@teaparty.net *Subject:* Re: Hardware migration process****
On Thu, Jun 27, 2013 at 4:53 AM, tmac tmacmd@gmail.com wrote:****
Personally, since the 6080 is supported all the way to 8.2, I would****
upgrade 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 same or as close to the same as possible.****
Save the headaches of significant multiple changes at once.****
I was hoping skipping the OS upgrade of the root drives was going to be one less significant change :-) ****
Do you have ha? Other concerns there too if you do****
(like local mailbox, making sure the right heads get the right disks, etc)
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****
--tmac****
*Tim McCarthy*****
*Principal Consultant* ****
Clustered ONTAP Clustered ONTAP****
NCDA ID: XK7R3GEKC1QQ2LVD RHCE5 805007643429572 NCSIE ID: C14QPHE21FR4YWD4****
Expires: 08 November 2014 Expires w/release of RHEL7 Expires: 08 November 2014****
On 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****
-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611****
Well, if the level of firmware you want to be on is only delivered with the new os, then it is not a requirement for the upgrade, so no worries.
Also, support always tells you 24 hours, but if you count the disks that need the firmware upgrade and multiply by 3m, that should give you a better idea of how long it will actually take.
Also, if you have not, you should run Configuration Advisor and see if it points out anything you/we didn't think of and request an Upgrade Advisor from the boys in blue.
--JMS
From: Jeff Cleverley [mailto:jeff.cleverley@avagotech.com] Sent: Thursday, June 27, 2013 12:11 PM To: Jordan Slingerland Cc: tmac; Toasters@teaparty.net Subject: Re: Hardware migration process
Unfortunately the main drives that need to have the firmware upgraded are the MOOS drives. That level of firmware is only delivered with the new OS. I was planning on letting it do the firmware upgrades during the outage window after moving the drives to the new hardware that has the correct OS.
Jeff On Thu, Jun 27, 2013 at 10:01 AM, Jordan Slingerland <Jordan.Slingerland@independenthealth.commailto:Jordan.Slingerland@independenthealth.com> wrote: You will want to upgrade your disk firmware prior to the upgrade as it upgrades 1 disks at a time and takes 2-3 minutes each disk.
--JMS
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net] On Behalf Of Jeff Cleverley Sent: Thursday, June 27, 2013 11:56 AM To: tmac Cc: <Toasters@teaparty.netmailto:Toasters@teaparty.net> Subject: Re: Hardware migration process
On Thu, Jun 27, 2013 at 4:53 AM, tmac <tmacmd@gmail.commailto:tmacmd@gmail.com> wrote: Personally, since the 6080 is supported all the way to 8.2, I would upgrade 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 same or as close to the same as possible. Save the headaches of significant multiple changes at once.
I was hoping skipping the OS upgrade of the root drives was going to be one less significant change :-)
Do you have ha? Other concerns there too if you do (like local mailbox, making sure the right heads get the right disks, etc)
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
--tmac
Tim McCarthy Principal Consultant
Clustered ONTAP Clustered ONTAP NCDA ID: XK7R3GEKC1QQ2LVD RHCE5 805007643429572 NCSIE ID: C14QPHE21FR4YWD4 Expires: 08 November 2014 Expires w/release of RHEL7 Expires: 08 November 2014
On Wed, Jun 26, 2013 at 12:25 PM, Jeff Cleverley <jeff.cleverley@avagotech.commailto: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-4611tel:970-288-4611 _______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
On Thu, Jun 27, 2013 at 10:15 AM, Jordan Slingerland < Jordan.Slingerland@independenthealth.com> wrote:
Well, if the level of firmware you want to be on is only delivered with the new os, then it is not a requirement for the upgrade, so no worries.** **
Also, support always tells you 24 hours, but if you count the disks that need the firmware upgrade and multiply by 3m, that should give you a better idea of how long it will actually take.
I'm not too worried if the disk upgrades extending beyond the maintenance window. I'll do the math and figure out how many will need upgrades and see how long it takes. I might consider upgrading selected firmware in the evenings if there are disks I can get firmware for without the OS upgrade. The systems have been running near the edge lately and I've been told don't do anything that could cause any panics or outages. Some people have no sense of adventure :-)
Also, if you have not, you should run Configuration Advisor and see if it points out anything you/we didn’t think of and request an Upgrade Advisor from the boys in blue.
What is Configuration Advisor? I run the sysconfig -c on all hardware and that is happy. I have also run the Upgrade Advisor and it didn't raise any flags. All that really deals with is the OS upgrade and not a hardware migration though.
Jeff
--JMS****
*From:* Jeff Cleverley [mailto:jeff.cleverley@avagotech.com] *Sent:* Thursday, June 27, 2013 12:11 PM *To:* Jordan Slingerland *Cc:* tmac; Toasters@teaparty.net
*Subject:* Re: Hardware migration process****
Unfortunately the main drives that need to have the firmware upgraded are the MOOS drives. That level of firmware is only delivered with the new OS. I was planning on letting it do the firmware upgrades during the outage window after moving the drives to the new hardware that has the correct OS.
Jeff****
On Thu, Jun 27, 2013 at 10:01 AM, Jordan Slingerland < Jordan.Slingerland@independenthealth.com> wrote:****
You will want to upgrade your disk firmware prior to the upgrade as it upgrades 1 disks at a time and takes 2-3 minutes each disk.****
--JMS****
*From:* toasters-bounces@teaparty.net [mailto: toasters-bounces@teaparty.net] *On Behalf Of *Jeff Cleverley *Sent:* Thursday, June 27, 2013 11:56 AM *To:* tmac *Cc:* Toasters@teaparty.net *Subject:* Re: Hardware migration process****
On Thu, Jun 27, 2013 at 4:53 AM, tmac tmacmd@gmail.com wrote:****
Personally, since the 6080 is supported all the way to 8.2, I would****
upgrade 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 same or as close to the same as possible.****
Save the headaches of significant multiple changes at once.****
I was hoping skipping the OS upgrade of the root drives was going to be one less significant change :-) ****
Do you have ha? Other concerns there too if you do****
(like local mailbox, making sure the right heads get the right disks, etc)
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****
--tmac****
*Tim McCarthy*****
*Principal Consultant* ****
Clustered ONTAP Clustered ONTAP****
NCDA ID: XK7R3GEKC1QQ2LVD RHCE5 805007643429572 NCSIE ID: C14QPHE21FR4YWD4****
Expires: 08 November 2014 Expires w/release of RHEL7 Expires: 08 November 2014****
On 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****
-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611****
-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611****
Formerly called Wire Gauge.
http://support.netapp.com/NOW/download/tools/config_advisor/ (now account required)
Correct, more geared toward os upgrade.
From: Jeff Cleverley [mailto:jeff.cleverley@avagotech.com] Sent: Thursday, June 27, 2013 12:34 PM To: Jordan Slingerland Cc: tmac; Toasters@teaparty.net Subject: Re: Hardware migration process
On Thu, Jun 27, 2013 at 10:15 AM, Jordan Slingerland <Jordan.Slingerland@independenthealth.commailto:Jordan.Slingerland@independenthealth.com> wrote: Well, if the level of firmware you want to be on is only delivered with the new os, then it is not a requirement for the upgrade, so no worries.
Also, support always tells you 24 hours, but if you count the disks that need the firmware upgrade and multiply by 3m, that should give you a better idea of how long it will actually take.
I'm not too worried if the disk upgrades extending beyond the maintenance window. I'll do the math and figure out how many will need upgrades and see how long it takes. I might consider upgrading selected firmware in the evenings if there are disks I can get firmware for without the OS upgrade. The systems have been running near the edge lately and I've been told don't do anything that could cause any panics or outages. Some people have no sense of adventure :-)
Also, if you have not, you should run Configuration Advisor and see if it points out anything you/we didn't think of and request an Upgrade Advisor from the boys in blue.
What is Configuration Advisor? I run the sysconfig -c on all hardware and that is happy. I have also run the Upgrade Advisor and it didn't raise any flags. All that really deals with is the OS upgrade and not a hardware migration though.
Jeff
--JMS
From: Jeff Cleverley [mailto:jeff.cleverley@avagotech.commailto:jeff.cleverley@avagotech.com] Sent: Thursday, June 27, 2013 12:11 PM To: Jordan Slingerland Cc: tmac; <Toasters@teaparty.netmailto:Toasters@teaparty.net>
Subject: Re: Hardware migration process
Unfortunately the main drives that need to have the firmware upgraded are the MOOS drives. That level of firmware is only delivered with the new OS. I was planning on letting it do the firmware upgrades during the outage window after moving the drives to the new hardware that has the correct OS.
Jeff On Thu, Jun 27, 2013 at 10:01 AM, Jordan Slingerland <Jordan.Slingerland@independenthealth.commailto:Jordan.Slingerland@independenthealth.com> wrote: You will want to upgrade your disk firmware prior to the upgrade as it upgrades 1 disks at a time and takes 2-3 minutes each disk.
--JMS
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net] On Behalf Of Jeff Cleverley Sent: Thursday, June 27, 2013 11:56 AM To: tmac Cc: <Toasters@teaparty.netmailto:Toasters@teaparty.net> Subject: Re: Hardware migration process
On Thu, Jun 27, 2013 at 4:53 AM, tmac <tmacmd@gmail.commailto:tmacmd@gmail.com> wrote: Personally, since the 6080 is supported all the way to 8.2, I would upgrade 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 same or as close to the same as possible. Save the headaches of significant multiple changes at once.
I was hoping skipping the OS upgrade of the root drives was going to be one less significant change :-)
Do you have ha? Other concerns there too if you do (like local mailbox, making sure the right heads get the right disks, etc)
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
--tmac
Tim McCarthy Principal Consultant
Clustered ONTAP Clustered ONTAP NCDA ID: XK7R3GEKC1QQ2LVD RHCE5 805007643429572 NCSIE ID: C14QPHE21FR4YWD4 Expires: 08 November 2014 Expires w/release of RHEL7 Expires: 08 November 2014
On Wed, Jun 26, 2013 at 12:25 PM, Jeff Cleverley <jeff.cleverley@avagotech.commailto: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-4611tel:970-288-4611 _______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
Thanks. I forgot they changed the name. I'll go get a new copy and see what it has.
Jeff
On Thu, Jun 27, 2013 at 10:57 AM, Jordan Slingerland < Jordan.Slingerland@independenthealth.com> wrote:
Formerly called Wire Gauge. ****
http://support.netapp.com/NOW/download/tools/config_advisor/ (now account required) ****
Correct, more geared toward os upgrade. ****
*From:* Jeff Cleverley [mailto:jeff.cleverley@avagotech.com] *Sent:* Thursday, June 27, 2013 12:34 PM
*To:* Jordan Slingerland *Cc:* tmac; Toasters@teaparty.net *Subject:* Re: Hardware migration process****
On Thu, Jun 27, 2013 at 10:15 AM, Jordan Slingerland < Jordan.Slingerland@independenthealth.com> wrote:****
Well, if the level of firmware you want to be on is only delivered with the new os, then it is not a requirement for the upgrade, so no worries.** **
Also, support always tells you 24 hours, but if you count the disks that need the firmware upgrade and multiply by 3m, that should give you a better idea of how long it will actually take.****
I'm not too worried if the disk upgrades extending beyond the maintenance window. I'll do the math and figure out how many will need upgrades and see how long it takes. I might consider upgrading selected firmware in the evenings if there are disks I can get firmware for without the OS upgrade. The systems have been running near the edge lately and I've been told don't do anything that could cause any panics or outages. Some people have no sense of adventure :-)****
Also, if you have not, you should run Configuration Advisor and see if it points out anything you/we didn’t think of and request an Upgrade Advisor from the boys in blue.****
What is Configuration Advisor? I run the sysconfig -c on all hardware and that is happy. I have also run the Upgrade Advisor and it didn't raise any flags. All that really deals with is the OS upgrade and not a hardware migration though.
Jeff ****
--JMS****
*From:* Jeff Cleverley [mailto:jeff.cleverley@avagotech.com] *Sent:* Thursday, June 27, 2013 12:11 PM *To:* Jordan Slingerland *Cc:* tmac; Toasters@teaparty.net****
*Subject:* Re: Hardware migration process****
Unfortunately the main drives that need to have the firmware upgraded are the MOOS drives. That level of firmware is only delivered with the new OS. I was planning on letting it do the firmware upgrades during the outage window after moving the drives to the new hardware that has the correct OS.
Jeff****
On Thu, Jun 27, 2013 at 10:01 AM, Jordan Slingerland < Jordan.Slingerland@independenthealth.com> wrote:****
You will want to upgrade your disk firmware prior to the upgrade as it upgrades 1 disks at a time and takes 2-3 minutes each disk.****
--JMS****
*From:* toasters-bounces@teaparty.net [mailto: toasters-bounces@teaparty.net] *On Behalf Of *Jeff Cleverley *Sent:* Thursday, June 27, 2013 11:56 AM *To:* tmac *Cc:* Toasters@teaparty.net *Subject:* Re: Hardware migration process****
On Thu, Jun 27, 2013 at 4:53 AM, tmac tmacmd@gmail.com wrote:****
Personally, since the 6080 is supported all the way to 8.2, I would****
upgrade 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 same or as close to the same as possible.****
Save the headaches of significant multiple changes at once.****
I was hoping skipping the OS upgrade of the root drives was going to be one less significant change :-) ****
Do you have ha? Other concerns there too if you do****
(like local mailbox, making sure the right heads get the right disks, etc)
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****
--tmac****
*Tim McCarthy*****
*Principal Consultant* ****
Clustered ONTAP Clustered ONTAP****
NCDA ID: XK7R3GEKC1QQ2LVD RHCE5 805007643429572 NCSIE ID: C14QPHE21FR4YWD4****
Expires: 08 November 2014 Expires w/release of RHEL7 Expires: 08 November 2014****
On 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****
-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611****
-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611****
-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611****
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.
Correct, the 64bit upgrade will not occur until you add disks to an aggregate bringing it beyond 16TB with the -64bit-upgrade switch. Also, I would like input from others, but I am not sure what the impact of just copying the /etc/ folder to the new unit. Specifically, I wonder what the effect of blindly copying the entire /etc/registry file. --Jordan NCDA/NCIE-BR
Jordan,
I only plan to have a copy of the /etc directory to view if I need to dig something up. I don't plan to copy it over the top of the new /etc directory on the new heads. It will be copied to something like /old_etc.
Jeff
On Thu, Jun 27, 2013 at 10:13 AM, Jordan Slingerland < Jordan.Slingerland@independenthealth.com> wrote:
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. ****
Correct, the 64bit upgrade will not occur until you add disks to an aggregate bringing it beyond 16TB with the -64bit-upgrade switch. Also, I would like input from others, but I am not sure what the impact of just copying the /etc/ folder to the new unit. Specifically, I wonder what the effect of blindly copying the entire /etc/registry file.****
--Jordan****
NCDA/NCIE-BR****
Gotcha, yeah good idea, for sure do that.
From: Jeff Cleverley [mailto:jeff.cleverley@avagotech.com] Sent: Thursday, June 27, 2013 12:15 PM To: Jordan Slingerland Cc: tmac; Toasters@teaparty.net Subject: Re: Hardware migration process
Jordan,
I only plan to have a copy of the /etc directory to view if I need to dig something up. I don't plan to copy it over the top of the new /etc directory on the new heads. It will be copied to something like /old_etc.
Jeff On Thu, Jun 27, 2013 at 10:13 AM, Jordan Slingerland <Jordan.Slingerland@independenthealth.commailto:Jordan.Slingerland@independenthealth.com> wrote:
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.
Correct, the 64bit upgrade will not occur until you add disks to an aggregate bringing it beyond 16TB with the -64bit-upgrade switch. Also, I would like input from others, but I am not sure what the impact of just copying the /etc/ folder to the new unit. Specifically, I wonder what the effect of blindly copying the entire /etc/registry file. --Jordan NCDA/NCIE-BR
-- Jeff Cleverley Unix Systems Administrator 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611
-
Jeff Cleverley -
Jordan Slingerland -
tmac