<div dir="ltr"><div>Hello Jeff,<br><br></div>Yes, I can successfully run "lctl ping" from the client to the Lustre server and vice versa as you described in:<br><ul><li>Client on ib0 lnet can `lctl ping ip.of.mds.server@tcp0`</li><li>MDS on tcp0 can `lctl ping ip.of.client@o2ib`</li></ul><p>I have not yet run an iperf nor lnet selftest (lst). I can start on that now.</p><p>Thank you,</p><p>megan<br></p></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 27, 2018 at 3:37 PM, Jeff Johnson <span dir="ltr"><<a href="mailto:jeff.johnson@aeoncomputing.com" target="_blank">jeff.johnson@aeoncomputing.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Megan,<div><br></div><div>I assume by being able to ping from server and client you mean they can ping each other.</div><div><ul><li>Client on ib0 lnet can `lctl ping ip.of.mds.server@tcp0`</li><li>MDS on tcp0 can `lctl ping ip.of.client@o2ib`</li></ul><div>If so, can you verify sustained performant throughput from each end to the lnet router? On the tcp side you can run iperf (iperf2 or iperf3) to verify sustained and stable throughput on the ethernet side. You can use ib_send_bw from lnet router to client in a similar way to iperf. </div></div><div><br></div><div>Additionally, you can run lnet_selftest engaging the MDS and client. This will test the lnet layer only, if the ethernet or IB layers beneath are wonky then lnet and lnet_selftest will not be able to tell you why, just that it is.</div><div><br></div><div>lnet_selftest method.</div><div><br></div><div><ol><li>On both mds and client run `modprobe lnet_selftest`<br></li><li>On the MDS export </li><li>Save the below script on the MDS</li><li>On the MDS run `export LST_SESSION=41704170</li><li>Run the script.</li></ol></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div># lnet_selftest script</div></blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>conc=8</div><div>export LST_SESSION=41704170</div><div>lst new_session rw</div><div>lst add_group clients clients.ip.addr@o2ib</div><div>lst add_group servers mds.ip.addr@tcp<br></div><div>lst add_batch bulk_rw</div><div>lst add_test --batch bulk_rw --distribute 1:1 --concurrency ${conc} --from clients --to servers brw read size=1M</div><div>lst run bulk_rw</div><div>lst stat clients servers</div></blockquote><div><br></div><div>You will see performance stats reported for server and client. To stop, ctrl-c and then type `lst end_session`</div><div><br></div><div>The value of LST_SESSION is arbitrary but lnet_selftest needs it so the background processes can be killed when the benchmark ends.</div><div><br></div><div>If lnet_selftest fails then there is something wonky in the routing or the network layer (non-lustre) underneath it. </div><div><br></div><div>Make sense?</div><div><br></div><div>--Jeff</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Feb 27, 2018 at 12:08 PM, Ms. Megan Larko <span dir="ltr"><<a href="mailto:dobsonunit@gmail.com" target="_blank">dobsonunit@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hello List!<br><br></div>We have some 2.7.18 lustre servers using TCP.  Through some dual-homed Lustre LNet routes we desire to connect some Mellanox (mlx4) InfiniBand Lustre 2.7.0 clients.  <br><br></div>The "lctl ping" command works from both the server co-located MGS/MDS and from the client.<br></div>The mount of the TCP lustre server share from the IB client starts and then shortly thereafter fails with "Input/output error    Is the MGS running?"<br><br></div>The Lustre MDS at approximate 20 min. intervals from client mount request /var/log/messages reports:<br></div>Lustre: MGS: Client <string> (at A.B.C.D@o2ib) reconnecting <br><br></div>The IB client mount command:<br></div>mount -t lustre C.D.E.F@tcp0:/lustre /mnt/lustre<br><br></div>Waits about a minute then returns:<br></div>mount.lustre C.D.E.F@tcp0:/lustre at /mnt/lustre failed:  Input/output error<br></div>Is the MGS running?.<br><br></div>The IB client /var/log/messages file contains:<br></div>Lustre: client.c:19349:ptlrpc_expire_o<wbr>ne_request(()) @@@ Request sent has timed out for slow reply ...... -->MGCC.D.E.F@tcp was lost; in progress operations using this service will fail<br></div>LustreError: 15c-8: MGCC.D.E.F@tcp: The configuration from log 'lustre-client' failed (-5)  This may be the result of communication errors between this node and the MGS, a bad configuration, or other errors.  See the syslog for more information.<br></div>Lustre: MGCC.D.E.F@tcp: Connection restored to MGS (at C.D.E.F@tcp)<br></div>Lustre: Unmounted lustre-client<br></div>LustreError: 22939:0:(obd_mount.c:lustre_fi<wbr>ll_super()) Unable to mount (-5)<br><br></div>We have not (yet) set any non-default values on the Lustre File System.<br></div>*  Server: Lustre 2.7.18  CentOS Linux release 7.3.1611 (Core)  kernel 3.10.0-514.2.2.el7_lustre.x86_<wbr>64   The server is ethernet; no IB.<br><br></div>*  Client: Lustre-2.7.0  RHEL 6.8  kernel 2.6.32-696.3.2.el6.x86_64    The client uses Mellanox InfiniBand mlx4.<br><br></div>The mount point does exist on the client.   The firewall is not an issue; checked.  SELinux is disabled.<br><br></div>NOTE: The server does server the same /lustre file system to other TCP Lustre clients.<br></div>The client does mount other /lustre_mnt from other IB servers.<br><br></div><div>The info on <a href="http://wiki.lustre.org/Mounting_a_Lustre_File_System_on_Client_Nodes" target="_blank">http://wiki.lustre.org/Mountin<wbr>g_a_Lustre_File_System_on_<wbr>Client_Nodes</a> describes the situation exceedingly similar to ours.   I'm not sure what Lustre settings to check if I have not explicitly set any to be different that the default value.<br><br></div>Any hints would be genuinely appreciated.<br>Cheers,<br></div>megan<br><div><div><div><div><div><br></div></div></div></div></div></div>
<br></div></div>______________________________<wbr>_________________<br>
lustre-discuss mailing list<br>
<a href="mailto:lustre-discuss@lists.lustre.org" target="_blank">lustre-discuss@lists.lustre.or<wbr>g</a><br>
<a href="http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org" rel="noreferrer" target="_blank">http://lists.lustre.org/listin<wbr>fo.cgi/lustre-discuss-lustre.<wbr>org</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_5137568917366171392gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">------------------------------<br>Jeff Johnson<br>Co-Founder<br>Aeon Computing<br><br><a href="mailto:jeff.johnson@aeoncomputing.com" target="_blank">jeff.johnson@aeoncomputing.com</a><br><a href="http://www.aeoncomputing.com" target="_blank">www.aeoncomputing.com</a><br>t: <a href="tel:(858)%20412-3810" value="+18584123810" target="_blank">858-412-3810 x1001</a>   f: <a href="tel:(858)%20412-3845" value="+18584123845" target="_blank">858-412-3845</a><br>m: <a href="tel:(619)%20204-9061" value="+16192049061" target="_blank">619-204-9061</a><br><br><a href="https://maps.google.com/?q=4170+Morena+Boulevard,+Suite+D+-+San+Diego,+CA+92117&entry=gmail&source=g">4170 Morena Boulevard, Suite D - San Diego, CA 92117</a><div><br></div><div>High-Performance Computing / Lustre Filesystems / Scale-out Storage</div></div></div>
</div>
</blockquote></div><br></div>