toasters

toasters@lists.teaparty.net

2 participants
13529 discussions

download process for Data ONTAP 8..x usually takes 20 to 60 minutes
by Fletcher Cocquyt 02 Feb '12

02 Feb '12

from pg 54 of the NDU guide: Note: Activating Data ONTAP 8..x software images with the download process takes significantly longer than in earlier releases. The download process for Data ONTAP 8..x usually takes 20 to 60 minutes. Q: Is it safe to issue the download command a few days ahead of the planned maintenance window (to save time in the actual maintenance window?) thanks -- Fletcher Cocquyt Principal Engineer Information Resources and Technology (IRT) Stanford University School of Medicine Email: fcocquyt(a)stanford.edu Phone: (650) 724-7485

3 2

Service Processor / syslog
by Stuart Kendrick 01 Feb '12

01 Feb '12

Is there a way to configure the Service Processor to log via syslog? I like solving problems using syslog ... for forensics, I want to see each box logging its view of the incident as it unfolds ... yeah, precise time-stamping is an issue ... but still, the basic flow works well, and I can build a picture of what happened via the resulting correlation between various devices. But it seems like the SP can only log via e-mail (and only intermittently at that) http://now.netapp.com/NOW/knowledge/docs/ontap/rel801/html/ontap/sysadmin/G… ? --sk Stuart Kendrick FHCRC

2 2

NDU from 7.3.5.1P3 to 8.1RC2 supported?
by Fletcher Cocquyt 01 Feb '12

01 Feb '12

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

2 1

Re: NDU from 7.3.5.1P3 to 8.1RC2 supported?
by Fletcher Cocquyt 01 Feb '12

01 Feb '12

Thanks for the feedback Steve, I'm also running the netapp tool to check HA prior to failover: Are these partner network errors valid? Someone in the community forums said they are bogus ./ha-config-check.cgi -s na03 na04 == NetApp HA Configuration Checker v2.0.0 == Checking ssh logins ... Checking ssh logins ... OK Checking Data ONTAP versions... OK Checking licenses... OK Checking HA configuration identity... OK Checking cf status... OK Checking fcp cfmode settings... fcp: FCP is not licensed. N/A Checking options... OK Checking network configuration... c0a (192.168.1.152) on na03 does not have a partner on na04 c0b (192.168.2.173) on na03 does not have a partner on na04 c0a (192.168.1.84) on na04 does not have a partner on na03 c0b (192.168.2.95) on na04 does not have a partner on na03 na04-vif0-205 (17.25.104.11) on na04 does not have a partner on na03 Checking network config in /etc/rc NO PARTNER FOR na04-vif0-205 (17.25.104.23) ON na04 in /etc/rc HA configuration issue(s) found above. Please correct them and rerun this script. Done. -- Fletcher On Jan 31, 2012, at 10:29 AM, SW wrote: > Hi Fletcher, > > > I only have a subset of answers relating to your Toasters inquiry, but I thought I’d share what I can... > > > According to the upgrade guide for 8.1RC2 (attached to this e-mail), a NDU from 7.3.5.1P3 to 8.1RC2 is supported: > > > > From page 15: > > “Nondisruptive upgrades to releases in the Data ONTAP 8.1 7-Mode release family are supported > > from the following releases: > > • Any 8.0.x release > > • 7.3.2 and later 7.3.x releases” > > > > Good luck! > > Steve > > <upgrade.pdf>

2 1

Re: NDU from 7.3.5.1P3 to 8.1RC2 supported?
by Fletcher Cocquyt 31 Jan '12

31 Jan '12

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&rel=8.… 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(a)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 > > > >

2 1

EMS Events in syslog
by Stuart Kendrick 29 Jan '12

29 Jan '12

Some EMS Events show up in syslog: cf.fm.takeoverComplete:WARN 10Jan2012 12:58:22 cf.fsm.releasingReservations:INFO 10Jan2012 12:58:24 loghost> grep -e cf.fm.takeoverComplete -e cf.fsm.releasingReservations syslog Jan 10 12:58:22 toaster-b-svif1 [toaster-b (takeover): cf.fm.takeoverComplete:warning]: Cluster monitor: takeover completed Jan 10 12:58:24 toaster-b-svif1 [toaster-b (takeover): cf.fsm.releasingReservations:info]: Cluster monitor: Releasing disk reservations in preparation for giveback But others do not: fci.device.timeout:ERR 10Jan2012 12:52:36 fci.device.quiesce:INFO 10Jan2012 13:00:16 loghost> grep -e fc.device syslog loghost> syslog.conf: *.info /etc/messages *.info @loghost.company.com In fact, examining my toaster logs for the last two years: loghost> ls 20* toaster-logs-from-2010.txt toaster-logs-from-2011.txt loghost> grep cf.fm.takeover toaster-logs-from* | wc -l 70 loghost> grep fc.device toaster-logs-from-* | wc -l 0 loghost> How do I persuade EMS to send /everything/ to syslog? --sk Stuart Kendrick FHCRC

2 2

How long can Windows survive loss of storage?
by Stuart Kendrick 26 Jan '12

26 Jan '12

Hi folks, We have MS SQL Server (a handful of instances, riding on top of MS Cluster Services) attached via Fibre Channel to a filer. Whenever we perform a takeover, SQL Server crumps. The DBAs shut it down, restart, repair/restore their databases (unhappy times), life returns to normal. We've replicated this behavior a handful of times: every single time we experience a takeover, whether administratively or Murphy-induced. I'd like to think that we can do better than this. This particular filer services five clients: the two MS SQL Servers via Fibre Channel and three Exchange servers via iSCSI. The iSCSI clients notice the takeover, but their initiators do the multipath thing and ride through the event fine. In the log extract below (heavily edited), we can see the iSCSI and FCP services going down at 21:47:25. And coming back on-line at 21:47:40 (FCP) and 21:47:49 (iSCSI). The iSCSI client 'hamlet' re-establishes its session at 21:47:51. The rest of the log extract records the downward spiral of the Windows server 'custard-1'. To my way of thinking, iSCSI was unavailable for 24 seconds, FCP for 15 seconds. (1) Are the iSCSI and FCP services really and truly available once the 'fcp.service.startup' and 'iscsi.service.startup' messages are logged, or might there be a delay before storage is actually available to clients? (2) How could we shrink takeover times? (3) Why does MS Windows over FC have such trouble surviving a 15 second disruption to storage? (4) How could we increase MS Windows timeouts? (5) How long can /your/ MS Windows FCP clients survive an interruption to storage? Toaster: FAS3020 running 7.2.4 SQL Server Clients: Windows 2008 running SnapDrive & SnapManager for SQL Server Exchange Clients: Windows 2003 running SnapDrive & SnapManager for Exchange Log extract below --sk Stuart Kendrick FHCRC Feb 7 21:47:22 toaster-b-svif2 [toaster-b: cf.misc.operatorTakeover:warning]: Cluster monitor: takeover initiated by operator Feb 7 21:47:22 toaster-b-svif2 [toaster-b: cf.fsm.nfo.acceptTakeoverReq:warning]: Negotiated failover: accepting takeover request by partner, reason: operator initiated cf takeover. Asking partner to shutdown gracefully; will takeover in at most 180 seconds. Feb 7 21:47:25 toaster-a-svif2 [toaster-a: cf.fsm.nfo.startingGracefulShutdown:warning]: Negotiated failover: starting graceful shutdown. Feb 7 21:47:25 toaster-a-svif2 [toaster-a: kern.shutdown:notice]: System shut down because : "reboot". Feb 7 21:47:25 toaster-a-svif2 [toaster-a: iscsi.service.shutdown:info]: iSCSI service shutdown Feb 7 21:47:25 toaster-a-svif2 [toaster-a: fcp.service.shutdown:info]: FCP service shutdown Feb 7 21:47:32 toaster-b-svif2 [toaster-b: cf.fsm.firmwareStatus:info]: Cluster monitor: partner rebooting Feb 7 21:47:32 toaster-b-svif2 [toaster-b: cf.fsm.nfo.partnerShutdown:warning]: Negotiated failover: partner has shutdown Feb 7 21:47:32 toaster-b-svif2 [toaster-b: cf.fsm.takeover.nfo:info]: Cluster monitor: takeover attempted after 'cf takeover'. command Feb 7 21:47:32 toaster-b-svif2 [toaster-b: cf.fsm.stateTransit:warning]: Cluster monitor: UP --> TAKEOVER Feb 7 21:47:32 toaster-b-svif2 [toaster-b: cf.fm.takeoverStarted:warning]: Cluster monitor: takeover started Feb 7 21:47:34 toaster-b-svif2 [toaster-b: cf_takeover:info]: NVRAM takeover: partner nvram is disabled Feb 7 21:47:39 toaster-b-svif2 [toaster-a/toaster-b: wafl.takeover.nvram.missing:error]: WAFL takeover: no partner area found during wafl replay Feb 7 21:47:40 toaster-b-svif2 [toaster-a/toaster-b: wafl.replay.done:info]: WAFL log replay completed, 0 seconds Feb 7 21:47:40 toaster-b-svif2 [toaster-a/toaster-b: fcp.service.startup:info]: FCP service startup 1 sys Error custard-1 2010-02-07 21:47:44 61203 ontapdsm DSM ID 0400010d has transitioned to the failed state. 1 sys Error custard-1 2010-02-07 21:47:44 61203 ontapdsm DSM ID 04000107 has transitioned to the failed state. 1 sys Error custard-1 2010-02-07 21:47:44 61203 ontapdsm DSM ID 0400010b has transitioned to the failed state. 1 sys Error custard-1 2010-02-07 21:47:44 61203 ontapdsm DSM ID 0300010b has transitioned to the failed state. [...] 1 sys Error custard-1 2010-02-07 21:47:44 61142 ontapdsm Nexus ID 03000101 has failed. Feb 7 21:47:48 toaster-b-svif2 [toaster-a/toaster-b: cf.fm.takeoverDetectionSeconds.Default:warning]: option cf.takeover.detection.seconds is set to 10 seconds which is below the NetApp advised value of 15 seconds. False takeovers and/or takeovers without diagnostic core-dumps might occur. Feb 7 21:47:49 toaster-b-svif2 [toaster-a/toaster-b: iscsi.service.startup:info]: iSCSI service startup Feb 7 21:47:50 toaster-b-svif2 [toaster-b (takeover): cf.rsrc.transitTime:notice]: Top Takeover transit times wafl_restart=7400 {vdisk=7214, restarters=186}, wafl=5049, registry_prerc=613, registry_postrc_phase2=555, rc=553 {ifconfig=99, ifconfig=93, hostname=57, options=41, options=27, options=26, route=2, vif=1, vif=1, vif=1}, raid=525, registry_postrc_phase1=403, wafl_sync=241, raid_replay=221, cifs=216 Feb 7 21:47:50 toaster-b-svif2 [toaster-b (takeover): cf.fm.takeoverComplete:warning]: Cluster monitor: takeover completed Feb 7 21:47:50 toaster-b-svif2 [toaster-b (takeover): cf.fm.takeoverDuration:warning]: Cluster monitor: takeover duration time is 18 seconds Feb 7 21:47:51 toaster-b-svif2 [toaster-a/toaster-b: iscsi.notice:notice]: ISCSI: New session from initiator iqn.1990-04.org.fhcrc:hamlet.fhcrc.org at IP addr 10.111.152.44 Feb 7 21:47:51 toaster-a-svif1 [toaster-a/toaster-b: iscsi.notice:notice]: ISCSI: New session from initiator iqn.1990-04.org.fhcrc:hamlet.fhcrc.org at IP addr 10.111.152.44 1 sys Warning custard-1 2010-02-07 21:47:57 61051 ontapdsm DSM ID 03000100 failed path verification. 1 sys Warning custard-1 2010-02-07 21:47:57 61051 ontapdsm DSM ID 03000101 failed path verification. 1 sys Warning custard-1 2010-02-07 21:47:57 61051 ontapdsm DSM ID 03000102 failed path verification. 1 sys Warning custard-1 2010-02-07 21:47:57 61077 ontapdsm DSM ID 03000111 has initiated a fail-over. [...] 1 sys Error custard-1 2010-02-07 21:47:57 61124 ontapdsm The port servicing DSM ID 03000111 reported the logical unit did not respond to selection. [...] Feb 7 21:48:01 toaster-b-svif2 [toaster-b (takeover): monitor.globalStatus.critical:CRITICAL]: This node has taken over toaster-a. Feb 7 21:48:01 toaster-b-svif2 [toaster-a/toaster-b: monitor.globalStatus.critical:CRITICAL]: toaster-b has taken over this node. Feb 7 21:48:01 toaster-a-svif1 [toaster-a/toaster-b: monitor.globalStatus.critical:CRITICAL]: toaster-b has taken over this node. 1 sys Warning custard-1 2010-02-07 21:48:04 61204 ontapdsm DSM ID 0400010f is in the process of being removed. 1 sys Warning custard-1 2010-02-07 21:48:04 61205 ontapdsm DSM ID 0400010f was removed. 1 sys Warning custard-1 2010-02-07 21:48:04 61205 ontapdsm DSM ID 0400010e was removed. [...] 1 sys Error custard-1 2010-02-07 21:48:04 16 mpio A fail-over on DeviceMPIODisk108 occurred. [...] 1 sys Warning custard-1 2010-02-07 21:48:04 17 mpio DeviceMPIODisk108 is currently in a degraded state. One or more paths have failed though the process is now complete. Feb 7 21:48:09 toaster-b-svif2 [toaster-a/toaster-b: syslogd:info]: syslogd: restarted Feb 7 21:48:09 toaster-a-svif1 [toaster-a/toaster-b: syslogd:info]: syslogd: restarted Feb 7 21:48:11 toaster-b-svif2 [toaster-a/toaster-b: nbt.nbns.registrationComplete:info]: NBT: All CIFS name registrations have completed for the partner server. Feb 7 21:48:11 toaster-a-svif1 [toaster-a/toaster-b: nbt.nbns.registrationComplete:info]: NBT: All CIFS name registrations have completed for the partner server. 1 sys Warning custard-1 2010-02-07 21:48:24 129 ql2300 Reset to device DeviceRaidPort1 was issued. 1 sys Warning custard-1 2010-02-07 21:48:28 1123 ClusSvc The node lost communication with cluster node 'custard-2' on network 'Public (Team)'. 1 sys Warning custard-1 2010-02-07 21:48:28 1123 ClusSvc The node lost communication with cluster node 'custard-2' on network 'Private 172.16 (PCI)'. 1 sys Warning custard-1 2010-02-07 21:48:28 1123 ClusSvc The node lost communication with cluster node 'custard-2' on network 'Private 192.168 (Onboard)'. 1 sys Error custard-1 2010-02-07 21:48:43 1209 ClusDisk Cluster service is requesting a bus reset for device DeviceClusDisk0. Feb 7 21:48:46 toaster-b-svif2 [toaster-b (takeover): scsitarget.ispfct.targetReset:notice]: FCP Target 0b: Target was Reset by the Initiator at Port Id: 0x10000 (WWPN 2100001b3201ba33) 1 sys Error custard-1 2010-02-07 21:48:51 1209 ClusDisk Cluster service is requesting a bus reset for device DeviceClusDisk0. 1 sys Error custard-1 2010-02-07 21:48:53 1118 ClusNet Cluster service was terminated as requested by Node 2. 1 sys Error custard-1 2010-02-07 21:48:53 7031 Service Control Manager The Cluster Service service terminated unexpectedly. It has done this 1 time(s). The following corrective action will be taken in 60000 milliseconds: Restart the service. 5 sys Error custard-1 2010-02-07 21:48:54 1036 ClusSvc Cluster disk resource '' did not respond to a SCSI maintenance command. 1 sys Error custard-1 2010-02-07 21:48:54 1215 ClusSvc Cluster Network Name custard is no longer registered with its hosting system. The associated resource name is ''. 1 sys Error custard-1 2010-02-07 21:48:54 1077 ClusSvc The TCP/IP interface for Cluster IP Address '' has failed. 1 sys Warning custard-1 2010-02-07 21:48:56 50 Ntfs {Delayed Write Failed} Windows was unable to save all the data for the file . The data has been lost. This error may be caused by a failure of your computer hardware or network connection. Please try to save this file elsewhere. 1 sys Warning custard-1 2010-02-07 21:48:57 57 Ftdisk The system failed to flush data to the transaction log. Corruption may occur.

6 7

maximum NDMP sessions?
by Randy Rue 26 Jan '12

26 Jan '12

Hello All, We've previously been under the impression that our v3170 could only run 16 NDMP sessions at a time. But our reporting seems to show as many as 27 running. Did this change in our last upgrade? We're currently at 7.3.5.1P5 Randy

3 3

MS Cluster clients locked out of LUNs
by Stuart Kendrick 24 Jan '12

24 Jan '12

Hi folks, After a takeover, we find that some (though not all) LUNs allocated to Microsoft Clustering clients show up in the Microsoft GUI as 'offline' or 'failed'. Rebooting the clients doesn't help. When we disable the Cluster disk drivers (make the client a simple iSCSI client), we can connect, read & write, etc. On the filer side, no sign of a reservation. We've replicated this behavior on three occasions over the last year (every time we experience a takeover, either administratively induced or accident induced). The clients run SnapDrive & SnapManager for SQL Server. To resolve this, we copy our data off (while connected via the vanilla iSCSI client), destroy the LUNs, rebuild, copy data back. Alternatively, we can wait a few days (not sure how many), whereupon the issue resolves itself (we've seen this once ... test environment). Anyone else seen this? Insights? What might be happening? NetApp v3140 running 7.3.5.1P5 Spinning rust provided by 3Par T800 Clients running Win2008R2 --sk Stuart Kendrick FHCRC

2 1

read only role?
by Randy Rue 24 Jan '12

24 Jan '12

Hello All, Looking to add a read-only role for techs in our department who are investigating some things but don't need (or want) to risk breaking stuff. Is there a "standard" list of capabilities that can be added to a role that will give the ability to see stuff but not break stuff? Thanks in advance, Randy Rue

5 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters