Bill, thanks for the feedback Do you have any BugIDs associated with the issue you mention?
I'm working with our SE and using the bug tool
http://now.netapp.com/NOW/cgi-bin/bol?Type=AdvSearch&relselect=ONTAP&...
to review known 8.1RC2 issues
A bit more background: We have a standby cluster (fresh 8.1RC2 install NOT an upgrade) and once the prod cluster is NDU'ed to 8.1RC2 we plan to data motion off prod vfilers to it so we can do tray upgrades (including a fresh install of 8.1RC2 since our root vol0 is on old trays we are getting rid of)
thanks
I'm sorry, I don't have the Bug ID's. It happened in our Dev environment right before I left my previous job in December. The 32-64 bit conversion completely crashed one filer. It was the only one that we had tried to do a conversion by snapmirroring from 32 bit to 64 bit. We had to take the 64 bit aggregate offline to get the filer back up. On another filer, that had several volumes that crossed the 16TB RAW threshold, the pre-conversion process beat the filer into almost non-usability. It turns out that if the aggregate exceeds 16TB RAW then they assume you are probably going to convert it to 64 bit at some point and do a pre-conversion analysis process. In this case, the aggregates hosted volumes that were snapmirror destinations from our Production systems and were refreshed on a daily basis. This resulted in the aggregates and volumes being in a near constant state of pre-conversion analysis. These were both FAS3170 systems. To bring performance back to an acceptable level, we had to migrate all the volumes to aggregates that were less than 16TB RAW. So, by jumping the gun and going to a release candidate in an effort to get larger storage containers, we ended up having to go to smaller ones.
On Tue, Jan 31, 2012 at 1:53 PM, Fletcher Cocquyt fcocquyt@stanford.eduwrote:
Bill, thanks for the feedback Do you have any BugIDs associated with the issue you mention?
I'm working with our SE and using the bug tool
http://now.netapp.com/NOW/cgi-bin/bol?Type=AdvSearch&relselect=ONTAP&...
to review known 8.1RC2 issues
A bit more background: We have a standby cluster (fresh 8.1RC2 install NOT an upgrade) and once the prod cluster is NDU'ed to 8.1RC2 we plan to data motion off prod vfilers to it so we can do tray upgrades (including a fresh install of 8.1RC2 since our root vol0 is on old trays we are getting rid of)
thanks
Fletcher
On Jan 31, 2012, at 10:02 AM, Bill Holland wrote:
Unless it's a non-production environment I wouldn't go to 8.1RC2. Still issues with 64 bit conversion. Bad enough to crash a filer.
Sent from my Galaxy Nexus
Fletcher Cocquyt fcocquyt@stanford.edu wrote:
Hi, Is NDU from 7.3.5.1P3 to 8.1RC2 supported? we are planning to hot swap out the 8.1RC2 incompatible ESH2 modules in our 3270 cluster (8 of them) then proceed with a Non-disruptive Upgrade (NDU) from the current 7.3.5.1P3 to 8.1RC2.
What will the clients see during cluster head failover? Should we shutdown virtualmachines? Oracle?
Where is the current NDU doc? Any other gotchas for this kind of upgrade?
thanks
Fletcher