Zoltan, Here is the info on the LACP issue. I recently ran into it during a firmware/OneFS upgrade. Be advised that there is a fix for it, it may be helpful to reference the topic in OneFS release notes. This example is 8.0.0.7: https://emcservice.force.com/CustomersPartners/kA5f1000000L0KCCA0 .
In OneFS 8.0.0.6, 8.0.1.2, 8.1.0.2, and 8.1.1.1, when some of the ports of a lagg interface in LACP mode go down with other ports still active, OneFS treats the lagg interface as down with No Carrier status. If this lagg is the only interface for front end network, connection to the node from outside the cluster will be lost. These are the possible options for this upgrade: 1. Postpone the upgrade until the next Maintenance Release is available, which will resolve this issue. 2. Remove LACP as an interim step and proceed with the scheduled upgrade. A patch will be made available in the near future at which time you can re-enable LACP. 3. Proceed with the upgrade inclusive of LACP configuration, taking into consideration the potential connectivity issues, being aware of the risk of DU... not recommended. I initially put the upgrade on hold and they recently notified me that code addressing the issue had been released, we completed the upgrade and so far there have been no issues. If your Isilon is vulnerable to the issue it should surface in the pre-upgrade assessment. Rick Adamson Information Technology Southeastern Grocers LLC -----Original Message----- From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of Zoltan Forray Sent: Wednesday, September 5, 2018 3:07 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] [EXTERNAL] Re: nfstimeout on server ISILON storage * This email originated outside of the organization. Use caution when opening attachments or clicking links. * ---------------------------------------------------------------------- Rick, Thanks for the reply. I passed your comments to my SAN guy and he said: *Earth is connected to HHIsilon and it is running 8.1.0.4 **All the others are connected to ISPIsilon and it is running 8.0.0.4* *I'm pretty sure all the Cisco switchports are LACP and Isilon networking is configured for LACP. Can that person elaborate on that bug?* On Wed, Sep 5, 2018 at 12:00 PM Rhodes, Richard L. < rrho...@firstenergycorp.com> wrote: > We run our Isilon systems (OneFS 8.0.0.6) with active/passive failover. > When we put them in OneFS had a bug with LACP and wouldn't work, > forcing us to go active/passive. Due to other problems, we just > discussed with them converting from active/passive to LACP, but EMC > said there is still a bug in LACP support. > > Rick > > > > -----Original Message----- > From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of > Zoltan Forray > Sent: Wednesday, September 5, 2018 9:03 AM > To: ADSM-L@VM.MARIST.EDU > Subject: [EXTERNAL] Re: nfstimeout on server ISILON storage > > A pair of 10G links bonded - CISCO switches. > > On Tue, Sep 4, 2018 at 7:54 PM Skylar Thompson <skyl...@uw.edu> wrote: > > > Quick question - what's the data link protocol (Ethernet, IB, etc.) > > and link rate that you're using? > > > > On Tue, Sep 04, 2018 at 02:05:33PM -0400, Zoltan Forray wrote: > > > We are still fighting issues with ISILON storage. Our current > > > issue is > > with > > > NFS timeouts for the storage a server is using. We see message > > > like > > these > > > in the server /var/log > > > > > > Sep 4 13:21:49 earth kernel: nfs: server > hhisilonnfs23.rams.adp.vcu.edu > > > not responding, still trying > > > Sep 4 13:21:49 earth kernel: nfs: server > hhisilonnfs23.rams.adp.vcu.edu > > > not responding, still trying > > > Sep 4 13:21:49 earth kernel: nfs: server > hhisilonnfs23.rams.adp.vcu.edu > > > not responding, still trying > > > Sep 4 13:21:49 earth kernel: nfs: server > hhisilonnfs23.rams.adp.vcu.edu > > > not responding, still trying > > > Sep 4 13:22:14 earth kernel: nfs: server > hhisilonnfs23.rams.adp.vcu.edu > > > not responding, still trying > > > Sep 4 13:22:15 earth kernel: nfs: server > hhisilonnfs23.rams.adp.vcu.edu > > > not responding, still trying > > > Sep 4 13:22:16 earth kernel: nfs: server > hhisilonnfs23.rams.adp.vcu.edu > > OK > > > Sep 4 13:22:16 earth kernel: nfs: server > hhisilonnfs23.rams.adp.vcu.edu > > OK > > > Sep 4 13:22:16 earth kernel: nfs: server > hhisilonnfs23.rams.adp.vcu.edu > > OK > > > > > > OS folks say the NFS mount is setup as IBM recommends in various > > documents. > > > So they asked us to implement the nfstimeout option from this > > > document > ( > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ibm.com_suppo > rt_knowledgecenter_en_SSGSG7-5F7.1.0_com.ibm.itsm.client.doc_r-5Fopt-5 > Fnfstimeout.html&d=DwIBaQ&c=AzgFQeXLLKhxSQaoFCm29A&r=eqh5PzQPIsPArLoI_ > uV1mKvhIpcNP1MsClDPSJjFfxw&m=3t7pcfhcKW_mIziokHeyox6igDZ5UffGWBYiq8BrZ > xY&s=UnS3__1OHHr0fHDPlrsf7LqPDHDkNQwM7bBq7M0ChIU&e= > > ). > > > Yes I realize it is primarily for a client backup of an NFS mount, > > > but > > the > > > statement: > > > > > > Supported Clients This option is for all UNIX and Linux clients. > > > *The server can also define this option*. > > > > > > throws us - kind-of implying I can use this from the server > perspective? > > > But I can't find any documentation to support using it from the server. > > > > > > For you Linux guru's - this is what the mount says: > > > > > > hhisilonnfs23.rams.adp.vcu.edu:/ifs/NFS/TSM on /tsmnfs type nfs > > > > > > (rw,relatime,sync,vers=3,rsize=131072,wsize=524288,namlen=255,hard,pro > to=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.19.12,mountvers=3 > ,mountport=300,mountproto=udp,local_lock=none,addr=192.168.19.12) > > > > > > Any thoughts? Suggestion? Are we simply expecting too much from NFS? > > > > > > My OS person also asks why ISP is so slow to write to NFS? When > > > they > > did a > > > test copy of a large file to the NFS mount, they were getting > > > upwards > of > > 8G/s > > > vs 1.5-3G/s when TSM/ISP writes to it (via EMC monitoring tools). > > > > > > -- > > > *Zoltan Forray* > > > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator > > > Xymon Monitor Administrator VMware Administrator Virginia > > > Commonwealth University UCC/Office of Technology Services > > > www.ucc.vcu.edu zfor...@vcu.edu - 804-828-4807 Don't be a phishing > > > victim - VCU and other reputable organizations will never use > > > email to request that you reply with your password, social > > > security number or confidential personal information. For more > > > details visit > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__phishing.vcu.e > > > du_&d=DwIBaQ&c=AzgFQeXLLKhxSQaoFCm29A&r=eqh5PzQPIsPArLoI_uV1mKvhIp > > > cNP1MsClDPSJjFfxw&m=3t7pcfhcKW_mIziokHeyox6igDZ5UffGWBYiq8BrZxY&s= > > > 6EKwxMcSvM4fPryVXlZ0YRXzo5ViyFbrUJpZiBsaMdE&e= > > > > -- > > -- Skylar Thompson (skyl...@u.washington.edu) > > -- Genome Sciences Department, System Administrator > > -- Foege Building S046, (206)-685-7354 > > -- University of Washington School of Medicine > > > > > -- > *Zoltan Forray* > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon > Monitor Administrator VMware Administrator Virginia Commonwealth > University UCC/Office of Technology Services www.ucc.vcu.edu > zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and > other reputable organizations will never use email to request that you > reply with your password, social security number or confidential > personal information. For more details visit > https://urldefense.proofpoint.com/v2/url?u=http-3A__phishing.vcu.edu_&; > d=DwIBaQ&c=AzgFQeXLLKhxSQaoFCm29A&r=eqh5PzQPIsPArLoI_uV1mKvhIpcNP1MsCl > DPSJjFfxw&m=3t7pcfhcKW_mIziokHeyox6igDZ5UffGWBYiq8BrZxY&s=6EKwxMcSvM4f > PryVXlZ0YRXzo5ViyFbrUJpZiBsaMdE&e= > > ---------------------------------------------------------------------- > -------- > > 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. > -- *Zoltan Forray* Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon Monitor Administrator VMware Administrator Virginia Commonwealth University UCC/Office of Technology Services www.ucc.vcu.edu zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit https://urldefense.proofpoint.com/v2/url?u=http-3A__phishing.vcu.edu_&d=DwIBaQ&c=AzgFQeXLLKhxSQaoFCm29A&r=eqh5PzQPIsPArLoI_uV1mKvhIpcNP1MsClDPSJjFfxw&m=3t7pcfhcKW_mIziokHeyox6igDZ5UffGWBYiq8BrZxY&s=6EKwxMcSvM4fPryVXlZ0YRXzo5ViyFbrUJpZiBsaMdE&e= **CONFIDENTIALITY NOTICE** This electronic message contains information from Southeastern Grocers, Inc and is intended only for the use of the addressee. This message may contain information that is privileged, confidential and/or exempt from disclosure under applicable Law. This message may not be read, used, distributed, forwarded, reproduced or stored by any other than the intended recipient. If you are not the intended recipient, please delete and notify the sender.
