toasters June 2016

toasters@lists.teaparty.net

31 participants
14 discussions

FDMI reporting with qla2xxx driver on Linux
by Momonth 09 Dec '16

09 Dec '16

Hi, I recently noticed that qla2xxx (Qlogic HBAs) driver on Linux is capable of reporting FDMI. By default it sends "Linux-default", and I'm failing to see how to change it to actual host name as it becomes way more handy then =) Any ideas? Cheers, Vladimir

2 3

cDOT cluster replication aka peering via specific LIFs
by Momonth 13 Jul '16

13 Jul '16

Hi All, I have two production cDOT clusters out of 8 nodes in two DCs, running OnTAP 8.3.2. I ended up having a bit of a weird network topology where 6 nodes (3 pairs) are only 1Gb enabled and 2 nodes (1 pair) are 10Gb enabled. I wonder how can I enforce cluster peering traffic via those 10Gb enabled nodes? I know that I have to have ICL LIFs on every node in the clusters, and that's fine, I can do that, but would like to set something like a preference for ICL traffic to flow via 10Gb enabled LIFs. Cheers, Vladimir

5 20

OnTap read block size?
by Rhodes, Richard L. 06 Jul '16

06 Jul '16

OnTap 8.1.2p1 Our DBA's are complaining that our nSeries (N3220/FAS2240) is reading really slow due to it only returning small 16k blocks. The DBA's are saying the Oracle multi-block read ahead should be reading 128 x 16k blocks = 2m read, but it's only seems to be reading/returning 16k at a time. On a AIX filesystem mounted CIO, if I run "dd if=/dev/zero of=z bs=1m count=9999" I see writes of 500k. In the same filesystem mounted CIO, if I read an existing db file "dd if=<dbfile> of=/dev/null bs=1m" I see reads of up to 30k. Q) Is there a limit in OnTap on read size? Thanks Rick ----------------------------------------- The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.

6 9

Intercluster lifs use an ifgroup but and local target is itself
by Joel Krajden 04 Jul '16

04 Jul '16

There were warnings the last time I upgraded cDOT from 8.3.2RC2 to 8.3.2 GA and again when going from 8.3.2GA to 8.3.2P1 The warnings had no errors associate with them and the upgrade failover/giveback completed without any problems. I wonder if the warnings are related to the fact that each node in the HA cluster has an an ifgroup using two 10G physical ports. The ifgroup a0a is shared using one vlan for the data lifs, and another vlan for the IC lifs. The data lifs failover to the other node's data lifs but the IC lifs failover to the local node where the target is itself. The network infrastructure between the separate buildings where the second cluster lives is such that we cannot use another set of physical ports for the intercluster lifs on the node. Are the vague warnings when upgrading hinting that this is not an optimal configuration? fc1-ev::> network interface show -vserver uperc -lif email.filers -failover Logical Home Failover Failover Vserver Interface Node:Port Policy Group -------- --------------- --------------------- --------------- --------------- uperc email.filers fc1-ev-n2:a0a-539 system-defined DATA_PUB Failover Targets: fc1-ev-n2:a0a-539, fc1-ev-n1:a0a-539 fc1-ev::> network interface show -role intercluster -failover * Logical Home Failover Failover Vserver Interface Node:Port Policy Group -------- --------------- --------------------- --------------- --------------- fc1-ev fc1-ev-n1_ic1 fc1-ev-n1:a0a-736 local-only IC Failover Targets: fc1-ev-n1:a0a-736 fc1-ev-n2_ic1 fc1-ev-n2:a0a-736 local-only IC Failover Targets: fc1-ev-n2:a0a-736 -- Joel Krajden: Core Technologies Manager Engineering & Computer Science Concordia University EV-8.142 Tel: 514 848-2424 3052 joelk(a)encs.concordia.ca

4 8

Filer controller down and auto failover issue
by Sayla, Mustafa 28 Jun '16

28 Jun '16

Last night we had an issue with our production filer where controller A went down but controller B did not know that A is down and did not took over. Only after I manually power off the controller A then controller B took over. I then brought the Controller A back up and did the give back and the filer worked fine for about 3 hours and same thing happened again. This time I shut down controller A and let it shut down and right now we are operating off of controller B only. Per netapp there is nothing in the logs that I sent them or in autosupport to suggest the root cause. They are asking us to bring controller A again and wait for it to happen again and if it does collect a core dump. This option is not acceptable to us as this affects production. Has anyone seen this before or have any ideas? Filer failover settings are all correct. We are running CDOT 8.3.1 on FAS8040. Mustafa Sayla Visit us on the Web at mesirowfinancial.com This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. Confidential, proprietary or time-sensitive communications should not be transmitted via the Internet, as there can be no assurance of actual or timely delivery, receipt and/or confidentiality. This is not an offer, or solicitation of any offer to buy or sell any security, investment or other product.

2 2

Interested in learning more about ONTAP 9?
by Parisi, Justin 28 Jun '16

28 Jun '16

In case you aren't aware, NetApp has an official podcast. This month, we've covered all things ONTAP 9 related. If you're interested, check it out! http://techontappodcast.com/

3 3

nfs access to volumes with ntfs security mode
by Peter D. Gray 27 Jun '16

27 Jun '16

Hi toasters We are migrating to cluster mode from 7 mode and having troubles with NFS access to volumes also doing CIFS. If I create a volume with NTFS security mode, and export aforesaid volume via NFS to a client, the client cannot read the volume. The mount suceeds, that is a filesystem handle is returned, but calls to access the directort fail, with message "file temporarily unavailable on the server, retrying..." The actual NFS error over the wire is is NFS3ERR_JUKEBOX. This is as root on the client. Non-root just gets permission denied. We have already set -ignore-nt-acl-for-root enabled on the vserver. The actuall settings on the vserver are: -access true \ -v3 enabled \ -udp enabled \ -tcp enabled \ -v4-id-domain its.uow.edu.au \ -v4.0 enabled \ -v4.1 enabled \ -v4.0-acl enabled \ -v4.1-acl enabled \ -v4.0-read-delegation enabled \ -v4.1-read-delegation enabled \ -v4.0-write-delegation enabled \ -v4.1-write-delegation enabled \ -v4.1-pnfs enabled \ -v4-numeric-ids enabled \ -mount-rootonly enabled \ -nfs-rootonly enabled \ -showmount enabled \ -vstorage disabled \ -ignore-nt-acl-for-root enabled So, what are we doing wrong or is this a bug? Regards, pdg Peter Gray Ph (direct): +61 2 4221 3770 Information Management & Technology Services Ph (switch): +61 2 4221 3555 University of Wollongong Fax: +61 2 4229 1958 Wollongong NSW 2522 Email: pdg(a)uow.edu.au Australia URL: http://pdg.uow.edu.au

2 1

Unable to terminate re-startable dumps
by John Adams 22 Jun '16

22 Jun '16

Hi All, We backup from a 3rd party product via NDMP. The past couple of days, SOME the backups have been failing on this filer with: There are no backup contexts available in the system. Delete some of the unwanted restartable backup contexts and retry the operation. DUMP: Maximum number of allowed dumps/restores (16) in progress. NDMP_OP_ERRORCODE is 'EMAXBACKUPS' DUMP: Dump failed to initialize. And looking at the filer: hostname*> backup status ID State Type Device Start Date Level Path -- ----------- ---- ------ ------------ ----- --------------- 2 RESTARTABLE dump 0 3 RESTARTABLE dump 0 4 RESTARTABLE dump 0 5 RESTARTABLE dump 0 6 RESTARTABLE dump 0 7 RESTARTABLE dump 0 8 RESTARTABLE dump 0 9 RESTARTABLE dump 0 10 RESTARTABLE dump 0 11 RESTARTABLE dump 0 12 RESTARTABLE dump 0 13 RESTARTABLE dump 0 14 RESTARTABLE dump 0 15 RESTARTABLE dump 0 16 RESTARTABLE dump 0 So I thought I had an accumulation of old backup sessions over time. hostname*> backup terminate 2 Unable to read from registry. There are no snapshots on the system that were created by backups right now. hostname*> version NetApp Release 8.2.3P3 7-Mode: Tue Apr 28 14:48:22 PDT 2015 Any ideas of what I could try here? Its strange that it shows dump as the device instead of NDMP. And its strange that the Start Date and Path's are blank. Thanks.

1 0

Raid disk layout - the ability to lose a shelf.
by jordan slingerland 22 Jun '16

22 Jun '16

Hello, I am deploying a new 8040 and it was requested that the aggregates / raid groups are laid out in such a way that no more than 2 disks in any raid group are within the same shelf. At first this sounds like it reduces single points of failure and could protect availability from the failure of a full disk shelf. I argue against this strategy and was wondering if anyone in this list had any feedback. My thought is that this configuration is marginally increasing availability at the sacrifice of additional risk to data integrity. With this strategy, each time a disk failed we would endure not only the initial rebuilt to spare, but a second rebuild when a disk replace is executed to put the original shelf/slot/disk back into the the active raid group. Additional, if a shelf failure were encountered, I question whether it would even be possible to limp along. In an example configuration, we would be down 24 disks, 4 or 5 would rebuild to the remaining spares available. Those rebuilds along should require significant cpu to occur concurrently and I expect would impact data services significantly. Additionally, at least 10 other raid groups would be either single or double degraded. I expect the performance degradation at this point would be so great that the most practical course of action would be to shutdown the system until the failed shelf could be replaced. Thanks for any input. I would like to know if anyone has any experience thinking through this type of scenario. Is considering this configuration interesting or perhaps silly? Are any best practice recommendations being violated? Thanks in advance. --Jordan

13 14

Netappdjenga
by Bert Kiers 21 Jun '16

21 Jun '16

Hi, A collegue fell off his chair when I proposed this game so I share the idea. Take a working Netapp metro cluster (preferably non-production). Players take turns to disconnect one connector until the cluster stops functioning. The player that disconnected the last one, loses. Grtnx, -- Bert

2 1

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 June 2016