I used the upgrade advisor plans sent by netapp. What is interesting is I never remember in past upgrades doing download on both filers. (is this something new?). I basically did this:
filer1> download (on one filer) filer1> version -b filer2> cf takeover
--- note, filer1 immediately rebooted here, with no option for me to issue a halt ----
as filer1 was coming back up, I noticed filer2 never completed his takeover. once filer1 was back up cf status reported cf disabled because of version mismatch.
So, was filer1 supposed to reboot right away when filer2 did a takeover? I am trying to figure out what I did wrong here, but I think I did all the steps ok. On the update of filer2 I did not have a problem, as I did a cf takeover -n there which allowed me to run halt there.
To answer the other person's post, failover has worked about a week prior so it's a known working cluster.
--- On Sat, 8/9/08, Strickland, Michael Michael.Strickland@netapp.com wrote:
From: Strickland, Michael Michael.Strickland@netapp.com Subject: RE: 7.0.6 to 7.2.5.1 upgrade To: juanino@yahoo.com, "list toasters" toasters@mathworks.com Date: Saturday, August 9, 2008, 2:01 PM That sometimes happens if you are attempting a non-disruptive upgrade and either miss a step, or something (download for example) does not complete as it should.
So, if you decide not to "cf disable", install, download, and reboot both heads individually (typical DISRUPTIVE upgrade), you have to follow steps simliar to the ones below.
- Install software to both nodes
- "download" on both nodes
- Run "version -b" to ensure that both nodes
have the new kernel version on the primary cf partition 4. filer1> cf takeover (filer2 now reboots, and you should notice the new kernel version mentioned. It then waits for giveback) 5. filer1> cf giveback -f (filer2 continues to boot) 6. At this point, filer2 is on the new ontap version, filer1 is downrev (takeover not possible) 7. filer1> halt (then immediately enter the following command on filer2) 8. filer2> cf takeover -n (-n switch used to allow NDU upgrade) 9. allow filer1 to boot and wait for giveback.. Note it should be on the new Ontap kernel at this point. 10. filer2> cf giveback -f 11. Check active version on each filer filer*> version
Note that these are the "basic" steps to perform a non-disruptive upgrade. More of an outline really. You should check the NOW site to ensure that Ontap versions involved are NDU capable, as well as any potential issues if SAN is involved.
Regards,
Michael Strickland Netapp Support
-----Original Message----- From: Jerry [mailto:juanino@yahoo.com] Sent: Friday, August 08, 2008 6:50 PM To: list toasters Subject: 7.0.6 to 7.2.5.1 upgrade
Has anyone experienced an issue going from 7.0.6 to 7.2.5.1. I did an upgrade on my 940 cluster and when I attempted takeover the takeover never succeeded. The first head decided to reboot (without me running halt) but the second head never completed the takeover.
After that it complained about version mismatch.