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.
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@stanford.eduwrote:
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
- Enter the following command to reboot the system using the new
firmware and software:
bye
- 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@stanford.edu* Phone: (650) 724-7485
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters