Sorry...As I understand the documentation I've read I think disk firmware updates are always disruptive unless you don't do more that what parity allows (1 disk per RG in raid4 or 2 disks in raid_DP) or unless your on 7.(Forgot the version - 0 or 1)) or later and your upgrading firmware as part of a reboot (the background upgrade option) - I've been thinking of raising a case asking for an enhancement about that as I couldn't see a way to drop new firmware on a box and let the nondisruptive upgrade process spin down and spin up one disk at a time (which is what it does if it sees new firmware after a reboot)
Happy to be proven I'm doing it wrong :)
_____
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Leeds, Daniel Sent: Saturday, 10 March 2007 2:58 AM To: Nils Vogels; tmac Cc: toasters@mathworks.com Subject: RE: Upgrading Data OnTap
on the fibre channel drive shelves it updates the firmware on both the a/b loop. if you run the shelf firmware updater on one side of the cluster you do not need to do it on the other side. it is also non disruptive and does not interfere with data access.
on the SATA shelves it is disruptive, the download command will tell you if it is disruptive or not before you proceed.
-- Daniel Leeds Senior Systems Administrator Edmunds.com
-----Original Message----- From: owner-toasters@mathworks.com on behalf of Nils Vogels Sent: Fri 3/9/2007 12:45 AM To: tmac Cc: toasters@mathworks.com Subject: Re: Upgrading Data OnTap
On 3/8/07, tmac tmacmd@gmail.com wrote:
Personally, I would:
copy the 7.1.2_setup_x.exe file to the /etc/software directory on each
filer.
Then from the console of each filer:
options raid.background_disk_fw_update.enable off (turns off auto updating of disk firmware) software install filename (the filename from above)
While at it, get and extract the latest all.zip and all_fw.zip files (disk and shelf FW) into the /etc dir on each filer.
Optionally, with cluster still enabled, run disk_fw_update to update all disk firmware (lessens downtime at reboot) usually only needed on one head. When complete, run on other head to be sure. storage download shelf to update shelf firmware (lessens downtime at reboot) usually only needed on one head. When complete, run on other head to be sure. options raid.background_disk_fw_update.enable on (turns the auto updating of disk firmware back on)
I'm preparing to do a NDU 7.0 -> 7.1 and was wondering: When you do the storage download shelf on one head, will it update the firmware on both the A-loop and B-loop ?
I would expect not, since one head is only connected to one loop in a plain cluster config. AFAIK, downloading shelf firmware takes a quiesce of a loop and a controller reboot, and my customer really would like to have a functional system during this NDU.
Greets,
Nils
-- Simple guidelines to happiness: Work like you don't need the money, Love like your heart has never been broken and Dance like no one can see you.
"This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ National Bank Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication."
i think two things got merged in this one, i was responding to the guy asking about storage shelf download updates not individual disk updates.
storage download shelf is non disruptive on FC loops but on SATA/ATA loops it is disruptive from my experience.
-- Daniel Leeds Senior Systems Administrator Edmunds.com
-----Original Message----- From: George, Andrew [mailto:georgea@anz.com] Sent: Fri 3/9/2007 4:08 PM To: Leeds, Daniel; Nils Vogels; tmac Cc: toasters@mathworks.com Subject: RE: Upgrading Data OnTap
Sorry...As I understand the documentation I've read I think disk firmware updates are always disruptive unless you don't do more that what parity allows (1 disk per RG in raid4 or 2 disks in raid_DP) or unless your on 7.(Forgot the version - 0 or 1)) or later and your upgrading firmware as part of a reboot (the background upgrade option) - I've been thinking of raising a case asking for an enhancement about that as I couldn't see a way to drop new firmware on a box and let the nondisruptive upgrade process spin down and spin up one disk at a time (which is what it does if it sees new firmware after a reboot)
Happy to be proven I'm doing it wrong :)
_____
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Leeds, Daniel Sent: Saturday, 10 March 2007 2:58 AM To: Nils Vogels; tmac Cc: toasters@mathworks.com Subject: RE: Upgrading Data OnTap
on the fibre channel drive shelves it updates the firmware on both the a/b loop. if you run the shelf firmware updater on one side of the cluster you do not need to do it on the other side. it is also non disruptive and does not interfere with data access.
on the SATA shelves it is disruptive, the download command will tell you if it is disruptive or not before you proceed.
-- Daniel Leeds Senior Systems Administrator Edmunds.com
-----Original Message----- From: owner-toasters@mathworks.com on behalf of Nils Vogels Sent: Fri 3/9/2007 12:45 AM To: tmac Cc: toasters@mathworks.com Subject: Re: Upgrading Data OnTap
On 3/8/07, tmac tmacmd@gmail.com wrote:
Personally, I would:
copy the 7.1.2_setup_x.exe file to the /etc/software directory on each
filer.
Then from the console of each filer:
options raid.background_disk_fw_update.enable off (turns off auto updating of disk firmware) software install filename (the filename from above)
While at it, get and extract the latest all.zip and all_fw.zip files (disk and shelf FW) into the /etc dir on each filer.
Optionally, with cluster still enabled, run disk_fw_update to update all disk firmware (lessens downtime at reboot) usually only needed on one head. When complete, run on other head to be sure. storage download shelf to update shelf firmware (lessens downtime at reboot) usually only needed on one head. When complete, run on other head to be sure. options raid.background_disk_fw_update.enable on (turns the auto updating of disk firmware back on)
I'm preparing to do a NDU 7.0 -> 7.1 and was wondering: When you do the storage download shelf on one head, will it update the firmware on both the A-loop and B-loop ?
I would expect not, since one head is only connected to one loop in a plain cluster config. AFAIK, downloading shelf firmware takes a quiesce of a loop and a controller reboot, and my customer really would like to have a functional system during this NDU.
Greets,
Nils
-- Simple guidelines to happiness: Work like you don't need the money, Love like your heart has never been broken and Dance like no one can see you.
"This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ National Bank Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication."
Actually as of 7.0.2 (I believe) it does exactly as you describe - you drop new disk FW in the right location and it starts disk FW upgrade on its own if a) you have RAID_DP or SyncMirror and b) you have option raid.background_disk_fw_update.enable set. This update is non-disruptive in the sense, aggregate continues to serve data.
This has changed at some point (it did not do it in 7.0.0.1 for sure); unfortunately it documentation for this options is rather vague; in particular in does not tell you update happens automatically.
Andrey Borzenkov
________________________________
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of George, Andrew Sent: Saturday, March 10, 2007 3:08 AM To: Leeds, Daniel; Nils Vogels; tmac Cc: toasters@mathworks.com Subject: RE: Upgrading Data OnTap
Sorry...As I understand the documentation I've read I think disk firmware updates are always disruptive unless you don't do more that what parity allows (1 disk per RG in raid4 or 2 disks in raid_DP) or unless your on 7.(Forgot the version - 0 or 1)) or later and your upgrading firmware as part of a reboot (the background upgrade option) - I've been thinking of raising a case asking for an enhancement about that as I couldn't see a way to drop new firmware on a box and let the nondisruptive upgrade process spin down and spin up one disk at a time (which is what it does if it sees new firmware after a reboot)
Happy to be proven I'm doing it wrong :)
________________________________
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Leeds, Daniel Sent: Saturday, 10 March 2007 2:58 AM To: Nils Vogels; tmac Cc: toasters@mathworks.com Subject: RE: Upgrading Data OnTap
on the fibre channel drive shelves it updates the firmware on both the a/b loop. if you run the shelf firmware updater on one side of the cluster you do not need to do it on the other side. it is also non disruptive and does not interfere with data access.
on the SATA shelves it is disruptive, the download command will tell you if it is disruptive or not before you proceed.
-- Daniel Leeds Senior Systems Administrator Edmunds.com
-----Original Message----- From: owner-toasters@mathworks.com on behalf of Nils Vogels Sent: Fri 3/9/2007 12:45 AM To: tmac Cc: toasters@mathworks.com Subject: Re: Upgrading Data OnTap
On 3/8/07, tmac tmacmd@gmail.com wrote:
Personally, I would:
copy the 7.1.2_setup_x.exe file to the /etc/software directory on each
filer.
Then from the console of each filer:
options raid.background_disk_fw_update.enable off (turns off auto updating of disk firmware) software install filename (the filename from above)
While at it, get and extract the latest all.zip and all_fw.zip files (disk and shelf FW) into the /etc dir on each filer.
Optionally, with cluster still enabled, run disk_fw_update to update all disk firmware (lessens downtime at reboot) usually only needed on one head. When complete, run on other head to be sure. storage download shelf to update shelf firmware (lessens downtime at reboot) usually only needed on one head. When complete, run on other head to be sure. options raid.background_disk_fw_update.enable on (turns the auto updating of disk firmware back on)
I'm preparing to do a NDU 7.0 -> 7.1 and was wondering: When you do the storage download shelf on one head, will it update the firmware on both the A-loop and B-loop ?
I would expect not, since one head is only connected to one loop in a plain cluster config. AFAIK, downloading shelf firmware takes a quiesce of a loop and a controller reboot, and my customer really would like to have a functional system during this NDU.
Greets,
Nils
-- Simple guidelines to happiness: Work like you don't need the money, Love like your heart has never been broken and Dance like no one can see you.
"This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ National Bank Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication."
-
Borzenkov, Andrey -
George, Andrew -
Leeds, Daniel