Mailing List Archive: Netapp: toasters

clarification about reboots during NDU

Index | Next | Previous | View Threaded

fcocquyt at stanford

Feb 2, 2012, 10:52 AM

Post #1 of 9 (1267 views)
Permalink

clarification about reboots during NDU

Hi - can someone clarify this from pg 56 of the upgrade guide -

for instance, if step 12 causes A to "reboot the system using the new firmware and software"

WHY in step 13 does the cf giveback ALSO "cause system A to reboot with the new system configuration?"

Are there really 2 reboots ?

thanks

12. Enter the following command to reboot the system using the new firmware and software:

bye

13. Choose the option that describes your configuration.

If FCP or iSCSI...

Is not in use in system A

Is in use in system A

Then when the "Waiting for giveback" message appears on the console of system A...

Enter the following command at the console of system B:

cf giveback

Wait for at least eight minutes to allow host multipathing software to stabilize, then enter the following command at the console of system B:

cf giveback

Attention: The cf giveback command can fail because of open client sessions (such as CIFS sessions), long-running operations, or operations that cannot be restarted (such as tape backup or SyncMirror resynchronization). If the cf giveback command fails, terminate any CIFS session or long-running operations gracefully (because the -f option will immediately terminate any CIFS sessions or long-running operations) and then enter the following command (with the -f option):

cf giveback -f
For more information about the behavior of the -f option, see the cf(1) man page.

The command causes system A to reboot with the new system configuration—a Data ONTAP version and any new system firmware and hardware changes—and resume normal operation as a high-availability partner.

--
Fletcher Cocquyt
Principal Engineer
Information Resources and Technology (IRT)
Stanford University School of Medicine

Email: fcocquyt [at] stanford
Phone: (650) 724-7485

Attachments:

page56image6248.png (2.67 KB)

page56image6520.png (2.68 KB)

page56image11776.png (2.67 KB)

page56image12048.png (2.68 KB)

page56image12320.png (2.67 KB)

page56image12592.png (2.68 KB)

page56image12864.png (2.67 KB)

page56image13136.png (2.68 KB)

image.jpg (9.10 KB)

tmacmd at gmail

Feb 2, 2012, 11:21 AM

Post #2 of 9 (1226 views)
Permalink

Re: clarification about reboots during NDU [In reply to]

There are 2 reboots, but it looks like 4 to the clients:

1. takeover #1 b->a (looks like very fast reboot to clients)
2. Wait for b to come back, then a give back happens (looks like very fast
reboot to clients)
3. Takeover #2 a-> (looks like very fast reboot to clients)
4. Wait for a to come back, then a give back happens (looks like very fast
reboot to clients)

So you actually only reboot each head once, but the takeover/giveback rack
up to four very brief outages.
With NFS, this is essentially non disruptive.

It is VERY disruptive to any CIFS clients due to the way they handle their
stateful sessions
(NFSv4 handles state very differently, even though it is stateful, it does
indeed survive the reboots without issues)
--tmac
Tim McCarthy
Principal Consultant

RedHat Certified Engineer
804006984323821 (RHEL4)
805007643429572 (RHEL5)

On Thu, Feb 2, 2012 at 1:52 PM, Fletcher Cocquyt <fcocquyt [at] stanford>wrote:

> Hi - can someone clarify this from pg 56 of the upgrade guide -
> for instance, if step 12 causes A to "reboot the system using the new
> firmware and software"
>
> WHY in step 13 does the cf giveback ALSO "*cause system A to reboot with
> the new system configuration?"*
> *
> *
> Are there really 2 reboots ?
> *
> *
> thanks
>
>
> 12. Enter the following command to reboot the system using the new
> firmware and software:
>
> bye
>
> 13. Choose the option that describes your configuration.
> [image: page56image6248]
> [image: page56image6520]
>
> If FCP or iSCSI...
>
> Is not in use in system A
>
> Is in use in system A
>
> Then when the "Waiting for giveback" message appears on the console of
> system A...
>
> Enter the following command at the console of system B:
>
> cf giveback
>
> Wait for at least eight minutes to allow host multipathing software to
> stabilize, then enter the following command at the console of system B:
>
> cf giveback
> [image: page56image11776]
> [image: page56image12048]
> [image: page56image12320]
> [image: page56image12592]
> [image: page56image12864]
> [image: page56image13136]
>
> Attention: The cf giveback command can fail because of open client
> sessions (such as CIFS sessions), long-running operations, or operations
> that cannot be restarted (such as tape backup or SyncMirror
> resynchronization). If the cf giveback command fails, terminate any CIFS
> session or long-running operations gracefully (because the -f option will
> immediately terminate any CIFS sessions or long-running operations) and
> then enter the following command (with the -f option):
>
> cf giveback -f
>
> For more information about the behavior of the -f option, see the cf(1)
> man page.
>
> *The command causes system A to reboot with the new system
> configuration—a Data ONTAP version and any new system firmware and hardware
> changes—and resume normal operation as a high-availability partner. *
> --
> Fletcher Cocquyt
> Principal Engineer
> Information Resources and Technology (IRT)
> Stanford University School of Medicine
>
> Email: *fcocquyt [at] stanford*
> Phone: (650) 724-7485
>
>
>
>
>
> _______________________________________________
> Toasters mailing list
> Toasters [at] teaparty
> http://www.teaparty.net/mailman/listinfo/toasters
>
>

Attachments:

page56image12864.png (2.67 KB)

page56image12592.png (2.68 KB)

page56image13136.png (2.68 KB)

image.jpg (9.10 KB)

page56image6520.png (2.68 KB)

page56image6248.png (2.67 KB)

page56image12320.png (2.67 KB)

page56image12048.png (2.68 KB)

page56image11776.png (2.67 KB)

fcocquyt at stanford

Feb 2, 2012, 11:24 AM

Post #3 of 9 (1222 views)
Permalink

Re: clarification about reboots during NDU [In reply to]

Justin, thanks for the feedback

What makes step 13 (cf giveback) triggering another reboot of the SAME node A is step 12 reads like that has already been accomplished for node A

so does node A reboot twice, then when you repeat the procedure, node B reboots twice?

thanks
--
Fletcher

On Feb 2, 2012, at 11:20 AM, Parisi, Justin wrote:

> In a takeover/giveback scenario, there are two reboots.
>
> The first reboot is the takeover. The second reboot is the giveback.
>
> From: toasters-bounces [at] teaparty [mailto:toasters-bounces [at] teaparty] On Behalf Of Fletcher Cocquyt
> Sent: Thursday, February 02, 2012 1:52 PM
> To: toasters [at] teaparty
> Subject: clarification about reboots during NDU
>
> Hi - can someone clarify this from pg 56 of the upgrade guide -
>
> for instance, if step 12 causes A to "reboot the system using the new firmware and software"
>
> WHY in step 13 does the cf giveback ALSO "cause system A to reboot with the new system configuration?"
>
> Are there really 2 reboots ?
>
> thanks
>
>
> 12. Enter the following command to reboot the system using the new firmware and software:
>
> bye
>
> 13. Choose the option that describes your configuration.
>
> <image001.png>
> <image002.png>
> If FCP or iSCSI...
>
> Is not in use in system A
>
> Is in use in system A
>
> Then when the "Waiting for giveback" message appears on the console of system A...
>
> Enter the following command at the console of system B:
>
> cf giveback
>
> Wait for at least eight minutes to allow host multipathing software to stabilize, then enter the following command at the console of system B:
>
> cf giveback
>
> <image001.png>
> <image002.png>
> <image001.png>
> <image002.png>
> <image001.png>
> <image002.png>
> Attention: The cf giveback command can fail because of open client sessions (such as CIFS sessions), long-running operations, or operations that cannot be restarted (such as tape backup or SyncMirror resynchronization). If the cf givebackcommand fails, terminate any CIFS session or long-running operations gracefully (because the -f option will immediately terminate any CIFS sessions or long-running operations) and then enter the following command (with the -f option):
>
> cf giveback -f
> For more information about the behavior of the -f option, see the cf(1) man page.
>
> The command causes system A to reboot with the new system configuration—a Data ONTAP version and any new system firmware and hardware changes—and resume normal operation as a high-availability partner.
>
> --
> Fletcher Cocquyt
> Principal Engineer
> Information Resources and Technology (IRT)
> Stanford University School of Medicine
> <image003.jpg>
>
> Email: fcocquyt [at] stanford
> Phone: (650) 724-7485
>
>
>
>

andrey.borzenkov at ts

Feb 2, 2012, 6:45 PM

Post #4 of 9 (1214 views)
Permalink

RE: clarification about reboots during NDU [In reply to]

"cf giveback" by itself does not cause extra reboot. Statement is manuals is confusing.

There could be multiple reboots of A indeed after "cf takeover" to update various firmware. This is entirely transparent as HA pair remains in "A taken over by B" state until A boots far enough to declare itself "ready for giveback".

________________________________________
From: toasters-bounces [at] teaparty [toasters-bounces [at] teaparty] On Behalf Of Fletcher Cocquyt [fcocquyt [at] stanford]
Sent: Thursday, February 02, 2012 23:24
To: Parisi, Justin
Cc: toasters [at] teaparty
Subject: Re: clarification about reboots during NDU

Justin, thanks for the feedback

What makes step 13 (cf giveback) triggering another reboot of the SAME node A is step 12 reads like that has already been accomplished for node A

so does node A reboot twice, then when you repeat the procedure, node B reboots twice?

thanks
--
Fletcher

On Feb 2, 2012, at 11:20 AM, Parisi, Justin wrote:

In a takeover/giveback scenario, there are two reboots.

The first reboot is the takeover. The second reboot is the giveback.

From: toasters-bounces [at] teaparty<mailto:toasters-bounces [at] teaparty> [mailto:toasters-bounces [at] teaparty] On Behalf Of Fletcher Cocquyt
Sent: Thursday, February 02, 2012 1:52 PM
To: toasters [at] teaparty<mailto:toasters [at] teaparty>
Subject: clarification about reboots during NDU

Hi - can someone clarify this from pg 56 of the upgrade guide -

for instance, if step 12 causes A to "reboot the system using the new firmware and software"

WHY in step 13 does the cf giveback ALSO "cause system A to reboot with the new system configuration?"

Are there really 2 reboots ?

thanks

12. Enter the following command to reboot the system using the new firmware and software:

bye

13. Choose the option that describes your configuration.

<image001.png>
<image002.png>

If FCP or iSCSI...

Is not in use in system A

Is in use in system A

Then when the "Waiting for giveback" message appears on the console of system A...

Enter the following command at the console of system B:

cf giveback

Wait for at least eight minutes to allow host multipathing software to stabilize, then enter the following command at the console of system B:

cf giveback

<image001.png>
<image002.png>
<image001.png>
<image002.png>
<image001.png>
<image002.png>

Attention: The cf giveback command can fail because of open client sessions (such as CIFS sessions), long-running operations, or operations that cannot be restarted (such as tape backup or SyncMirror resynchronization). If the cf givebackcommand fails, terminate any CIFS session or long-running operations gracefully (because the -f option will immediately terminate any CIFS sessions or long-running operations) and then enter the following command (with the -f option):

cf giveback -f

For more information about the behavior of the -f option, see the cf(1) man page.

The command causes system A to reboot with the new system configuration—a Data ONTAP version and any new system firmware and hardware changes—and resume normal operation as a high-availability partner.

--
Fletcher Cocquyt
Principal Engineer
Information Resources and Technology (IRT)
Stanford University School of Medicine
<image003.jpg>

Email: fcocquyt [at] stanford<x-msg://993/fcocquyt [at] stanford>
Phone: (650) 724-7485

_______________________________________________
Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

fcocquyt at stanford

Feb 2, 2012, 7:11 PM

Post #5 of 9 (1225 views)
Permalink

Re: clarification about reboots during NDU [In reply to]

Andrey - yes "confusing/ambiguous/hard to decipher" are all adjectives I'd use.
I find the Upgrade Advisor is much clearer, but it lacks the details for NDU - it merely refers to "if you are performing NDU…"

As it stands, the admin is left to piece together the upgrade steps from several different sources
I just finished the disk firmware upgrades on the first node recommended by Upgrade Advisor - but I made sure to call Netapp support specifically about the X410_HVIPC288A15 NA01 firmware and re-confirm it would be non-disruptive

Just copied X410_HVIPC288A15 NA01 to the second node's /etc/disk_fw - but its not initiating any firmware updates (first node started logging firmware update messages immediately)

How do I list the firmware of the X410_HVIPC288A15 disks?

disk show -T is not a valid option apparently any more in 7.3.5.1?

thanks
--
Fletcher

On Feb 2, 2012, at 6:45 PM, Borzenkov, Andrey wrote:

> "cf giveback" by itself does not cause extra reboot. Statement is manuals is confusing.
>
> There could be multiple reboots of A indeed after "cf takeover" to update various firmware. This is entirely transparent as HA pair remains in "A taken over by B" state until A boots far enough to declare itself "ready for giveback".
>
> ________________________________________
> From: toasters-bounces [at] teaparty [toasters-bounces [at] teaparty] On Behalf Of Fletcher Cocquyt [fcocquyt [at] stanford]
> Sent: Thursday, February 02, 2012 23:24
> To: Parisi, Justin
> Cc: toasters [at] teaparty
> Subject: Re: clarification about reboots during NDU
>
> Justin, thanks for the feedback
>
> What makes step 13 (cf giveback) triggering another reboot of the SAME node A is step 12 reads like that has already been accomplished for node A
>
> so does node A reboot twice, then when you repeat the procedure, node B reboots twice?
>
> thanks
> --
> Fletcher
>
>
>
> On Feb 2, 2012, at 11:20 AM, Parisi, Justin wrote:
>
> In a takeover/giveback scenario, there are two reboots.
>
> The first reboot is the takeover. The second reboot is the giveback.
>
> From: toasters-bounces [at] teaparty<mailto:toasters-bounces [at] teaparty> [mailto:toasters-bounces [at] teaparty] On Behalf Of Fletcher Cocquyt
> Sent: Thursday, February 02, 2012 1:52 PM
> To: toasters [at] teaparty<mailto:toasters [at] teaparty>
> Subject: clarification about reboots during NDU
>
>
> Hi - can someone clarify this from pg 56 of the upgrade guide -
>
> for instance, if step 12 causes A to "reboot the system using the new firmware and software"
>
> WHY in step 13 does the cf giveback ALSO "cause system A to reboot with the new system configuration?"
>
> Are there really 2 reboots ?
>
> thanks
>
>
>
> 12. Enter the following command to reboot the system using the new firmware and software:
>
> bye
>
> 13. Choose the option that describes your configuration.
>
> <image001.png>
> <image002.png>
>
> If FCP or iSCSI...
>
> Is not in use in system A
>
> Is in use in system A
>
> Then when the "Waiting for giveback" message appears on the console of system A...
>
> Enter the following command at the console of system B:
>
> cf giveback
>
> Wait for at least eight minutes to allow host multipathing software to stabilize, then enter the following command at the console of system B:
>
> cf giveback
>
> <image001.png>
> <image002.png>
> <image001.png>
> <image002.png>
> <image001.png>
> <image002.png>
>
> Attention: The cf giveback command can fail because of open client sessions (such as CIFS sessions), long-running operations, or operations that cannot be restarted (such as tape backup or SyncMirror resynchronization). If the cf givebackcommand fails, terminate any CIFS session or long-running operations gracefully (because the -f option will immediately terminate any CIFS sessions or long-running operations) and then enter the following command (with the -f option):
>
> cf giveback -f
>
> For more information about the behavior of the -f option, see the cf(1) man page.
>
> The command causes system A to reboot with the new system configuration—a Data ONTAP version and any new system firmware and hardware changes—and resume normal operation as a high-availability partner.
>
> --
> Fletcher Cocquyt
> Principal Engineer
> Information Resources and Technology (IRT)
> Stanford University School of Medicine
> <image003.jpg>
>
> Email: fcocquyt [at] stanford<x-msg://993/fcocquyt [at] stanford>
> Phone: (650) 724-7485
>
>
>
>
>

stever at up-south

Feb 2, 2012, 7:13 PM

Post #6 of 9 (1234 views)
Permalink

RE: clarification about reboots during NDU [In reply to]

>From a cifs perspective a give back is a reboot.
--
We are the 99%

"Borzenkov, Andrey" <andrey.borzenkov [at] ts> wrote:

"cf giveback" by itself does not cause extra reboot. Statement is manuals is confusing.

There could be multiple reboots of A indeed after "cf takeover" to update various firmware. This is entirely transparent as HA pair remains in "A taken over by B" state until A boots far enough to declare itself "ready for giveback".

_____________________________________________

From: toasters-bounces [at] teaparty [toasters-bounces [at] teaparty] On Behalf Of Fletcher Cocquyt [fcocquyt [at] stanford]
Sent: Thursday, February 02, 2012 23:24
To: Parisi, Justin
Cc: toasters [at] teaparty
Subject: Re: clarification about reboots during NDU

Justin, thanks for the feedback

What makes step 13 (cf giveback) triggering another reboot of the SAME node A is step 12 reads like that has already been accomplished for node A

so does node A reboot twice, then when you repeat the procedure, node B reboots twice?

thanks
--
Fletcher

On Feb 2, 2012, at 11:20 AM, Parisi, Justin wrote:

In a takeover/giveback scenario, there are two reboots.

The first reboot is the takeover. The second reboot is the giveback.

From: toasters-bounces [at] teaparty<mailto:toasters-bounces [at] teaparty> [mailto:toasters-bounces [at] teaparty] On Behalf Of Fletcher Cocquyt
Sent: Thursday, February 02, 2012 1:52 PM
To: toasters [at] teaparty<mailto:toasters [at] teaparty>
Subject: clarification about reboots during NDU

Hi - can someone clarify this from pg 56 of the upgrade guide -

for instance, if step 12 causes A to "reboot the system using the new firmware and software"

WHY in step 13 does the cf giveback ALSO "cause system A to reboot with the new system configuration?"

Are there really 2 reboots ?

thanks

12. Enter the following command to reboot the system using the new firmware and software:

bye

13. Choose the option that describes your configuration.

<image001.png>
<image002.png>

If FCP or iSCSI...

Is not in use in system A

Is in use in system A

Then when the "Waiting for giveback" message appears on the console of system A...

Enter the following command at the console of system B:

cf giveback

Wait for at least eight minutes to allow host multipathing software to stabilize, then enter the following command at the console of system B:

cf giveback

<image001.png>
<image002.png>
<image001.png>
<image002.png>
<image001.png>
<image002.png>

Attention: The cf giveback command can fail because of open client sessions (such as CIFS sessions), long-running operations, or operations that cannot be restarted (such as tape backup or SyncMirror resynchronization). If the cf givebackcommand fails, terminate any CIFS session or long-running operations gracefully (because the -f option will immediately terminate any CIFS sessions or long-running operations) and then enter the following command (with the -f option):

cf giveback -f

For more information about the behavior of the -f option, see the cf(1) man page.

The command causes system A to reboot with the new system configurationâ€”a Data ONTAP version and any new system firmware and hardware changesâ€”and resume normal operation as a high-availability partner.

--
Fletcher Cocquyt
Principal Engineer
Information Resources and Technology (IRT)
Stanford University School of Medicine
<image003.jpg>

Email: fcocquyt [at] stanford<x-msg://993/fcocquyt [at] stanford>
Phone: (650) 724-7485

_____________________________________________

Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

andrey.borzenkov at ts

Feb 2, 2012, 7:26 PM

Post #7 of 9 (1212 views)
Permalink

RE: clarification about reboots during NDU [In reply to]

Yes, you are absolutely right, but to quote OP: "confusing/ambiguous/hard to decipher" are all adjectives I'd use.

"Reboot" is far too ambiguous in this context.

________________________________________
From: Steve [stever [at] up-south]
Sent: Friday, February 03, 2012 07:13
To: Borzenkov, Andrey; Fletcher Cocquyt; Parisi, Justin
Cc: toasters [at] teaparty
Subject: RE: clarification about reboots during NDU

>From a cifs perspective a give back is a reboot.
--
We are the 99%

"Borzenkov, Andrey" <andrey.borzenkov [at] ts> wrote:

"cf giveback" by itself does not cause extra reboot. Statement is manuals is confusing.

There could be multiple reboots of A indeed after "cf takeover" to update various firmware. This is entirely transparent as HA pair remains in "A taken over by B" state until A boots far enough to declare itself "ready for giveback".

________________________________

From: toasters-bounces [at] teaparty [toasters-bounces [at] teaparty] On Behalf Of Fletcher Cocquyt [fcocquyt [at] stanford]
Sent: Thursday, February 02, 2012 23:24
To: Parisi, Justin
Cc: toasters [at] teaparty
Subject: Re: clarification about reboots during NDU

Justin, thanks for the feedback

What makes step 13 (cf giveback) triggering another reboot of the SAME node A is step 12 reads like that has already been accomplished for node A

so does node A reboot twice, then when you repeat the procedure, node
B reboots twice?

thanks
--
Fletcher

On Feb 2, 2012, at 11:20 AM, Parisi, Justin wrote:

In a takeover/giveback scenario, there are two reboots.

The first reboot is the takeover. The second reboot is the giveback.

From: toasters-bounces [at] teaparty<mailto:toasters-bounces [at] teaparty> [mailto:toasters-bounces [at] teaparty] On Behalf Of Fletcher Cocquyt
Sent: Thursday, February 02, 2012 1:52 PM
To: toasters [at] teaparty<mailto:toasters [at] teaparty>
Subject: clarification about reboots during NDU

Hi - can someone clarify this from pg 56 of the upgrade guide -

for instance, if step 12 causes A to "reboot the system using the new firmware and software"

WHY in step 13 does the cf giveback ALSO "cause system A to reboot with the new system configuration?"

Are there really 2 reboots ?

thanks

12. Enter
the following command to reboot the system using the new firmware and software:

bye

13. Choose the option that describes your configuration.

<image001.png>
<image002.png>

If FCP or iSCSI...

Is not in use in system A

Is in use in system A

Then when the "Waiting for giveback" message appears on the console of system A...

Enter the following command at the console of system B:

cf giveback

Wait for at least eight minutes to allow host multipathing software to stabilize, then enter the following command at the console of system B:

cf giveback

<image001.png>
<image002.png>
<image001.png>
<image002.png>
<image001.png>
<image002.png>

Attention: The cf giveback command can fail because of open client sessions (such as CIFS sessions), long-running operations, or operations
that cannot be restarted (such as tape backup or SyncMirror resynchronization). If the cf givebackcommand fails, terminate any CIFS session or long-running operations gracefully (because the -f option will immediately terminate any CIFS sessions or long-running operations) and then enter the following command (with the -f option):

cf giveback -f

For more information about the behavior of the -f option, see the cf(1) man page.

The command causes system A to reboot with the new system configuration—a Data ONTAP version and any new system firmware and hardware changes—and resume normal operation as a high-availability partner.

--
Fletcher Cocquyt
Principal Engineer
Information Resources and Technology (IRT)
Stanford University School of Medicine
<image003.jpg>

Email: fcocquyt [at] stanford<x-msg://993/fcocquyt [at] stanford>
Phone: (650) 724-7485

________________________________

Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

_______________________________________________
Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

andrey.borzenkov at ts

Feb 2, 2012, 7:30 PM

Post #8 of 9 (1227 views)
Permalink

RE: clarification about reboots during NDU [In reply to]

Use "sysconfig -v" or "storage show disk -x" to check current disk firmware.
________________________________________
From: Fletcher Cocquyt [fcocquyt [at] stanford]
Sent: Friday, February 03, 2012 07:11
To: Borzenkov, Andrey
Cc: Parisi, Justin; toasters [at] teaparty
Subject: Re: clarification about reboots during NDU

Andrey - yes "confusing/ambiguous/hard to decipher" are all adjectives I'd use.
I find the Upgrade Advisor is much clearer, but it lacks the details for NDU - it merely refers to "if you are performing NDU…"

As it stands, the admin is left to piece together the upgrade steps from several different sources
I just finished the disk firmware upgrades on the first node recommended by Upgrade Advisor - but I made sure to call Netapp support specifically about the X410_HVIPC288A15 NA01 firmware and re-confirm it would be non-disruptive

Just copied X410_HVIPC288A15 NA01 to the second node's /etc/disk_fw - but its not initiating any firmware updates (first node started logging firmware update messages immediately)

How do I list the firmware of the X410_HVIPC288A15 disks?

disk show -T is not a valid option apparently any more in 7.3.5.1?

thanks
--
Fletcher

On Feb 2, 2012, at 6:45 PM, Borzenkov, Andrey wrote:

"cf giveback" by itself does not cause extra reboot. Statement is manuals is confusing.

There could be multiple reboots of A indeed after "cf takeover" to update various firmware. This is entirely transparent as HA pair remains in "A taken over by B" state until A boots far enough to declare itself "ready for giveback".

________________________________________
From: toasters-bounces [at] teaparty<mailto:toasters-bounces [at] teaparty> [toasters-bounces [at] teaparty<mailto:toasters-bounces [at] teaparty>] On Behalf Of Fletcher Cocquyt [fcocquyt [at] stanford<mailto:fcocquyt [at] stanford>]
Sent: Thursday, February 02, 2012 23:24
To: Parisi, Justin
Cc: toasters [at] teaparty<mailto:toasters [at] teaparty>
Subject: Re: clarification about reboots during NDU

Justin, thanks for the feedback

What makes step 13 (cf giveback) triggering another reboot of the SAME node A is step 12 reads like that has already been accomplished for node A

so does node A reboot twice, then when you repeat the procedure, node B reboots twice?

thanks
--
Fletcher

On Feb 2, 2012, at 11:20 AM, Parisi, Justin wrote:

In a takeover/giveback scenario, there are two reboots.

The first reboot is the takeover. The second reboot is the giveback.

From: toasters-bounces [at] teaparty<mailto:toasters-bounces [at] teaparty><mailto:toasters-bounces [at] teaparty> [mailto:toasters-bounces [at] teaparty] On Behalf Of Fletcher Cocquyt
Sent: Thursday, February 02, 2012 1:52 PM
To: toasters [at] teaparty<mailto:toasters [at] teaparty><mailto:toasters [at] teaparty>
Subject: clarification about reboots during NDU

Hi - can someone clarify this from pg 56 of the upgrade guide -

for instance, if step 12 causes A to "reboot the system using the new firmware and software"

WHY in step 13 does the cf giveback ALSO "cause system A to reboot with the new system configuration?"

Are there really 2 reboots ?

thanks

12. Enter the following command to reboot the system using the new firmware and software:

bye

13. Choose the option that describes your configuration.

<image001.png>
<image002.png>

If FCP or iSCSI...

Is not in use in system A

Is in use in system A

Then when the "Waiting for giveback" message appears on the console of system A...

Enter the following command at the console of system B:

cf giveback

Wait for at least eight minutes to allow host multipathing software to stabilize, then enter the following command at the console of system B:

cf giveback

<image001.png>
<image002.png>
<image001.png>
<image002.png>
<image001.png>
<image002.png>

Attention: The cf giveback command can fail because of open client sessions (such as CIFS sessions), long-running operations, or operations that cannot be restarted (such as tape backup or SyncMirror resynchronization). If the cf givebackcommand fails, terminate any CIFS session or long-running operations gracefully (because the -f option will immediately terminate any CIFS sessions or long-running operations) and then enter the following command (with the -f option):

cf giveback -f

For more information about the behavior of the -f option, see the cf(1) man page.

The command causes system A to reboot with the new system configuration—a Data ONTAP version and any new system firmware and hardware changes—and resume normal operation as a high-availability partner.

--
Fletcher Cocquyt
Principal Engineer
Information Resources and Technology (IRT)
Stanford University School of Medicine
<image003.jpg>

Email: fcocquyt [at] stanford<mailto:fcocquyt [at] stanford><x-msg://993/fcocquyt [at] stanford>
Phone: (650) 724-7485

_______________________________________________
Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

jack1729 at gmail

Feb 2, 2012, 8:48 PM

Post #9 of 9 (1218 views)
Permalink

Re: clarification about reboots during NDU [In reply to]

If disks are available to both heads - the second head doesn't need to update any firmware.
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Fletcher Cocquyt <fcocquyt [at] stanford>
Sender: toasters-bounces [at] teaparty
Date: Thu, 2 Feb 2012 19:11:38
To: Borzenkov, Andrey<andrey.borzenkov [at] ts>
Cc: toasters [at] teaparty<toasters [at] teaparty>
Subject: Re: clarification about reboots during NDU

_______________________________________________
Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

_______________________________________________
Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads