<?xml version="1.0" encoding="UTF-8"?>
-<chapter version="5.0" xml:lang="en-US" xmlns="http://docbook.org/ns/docbook" xmlns:xl="http://www.w3.org/1999/xlink">
+<chapter version="5.0" xml:lang="en-US" xmlns="http://docbook.org/ns/docbook" xmlns:xl="http://www.w3.org/1999/xlink" xml:id='managinglnet'>
<info>
- <title>Managing Lustre Networking (LNET)</title>
+ <title xml:id='managinglnet.title'>Managing Lustre Networking (LNET)</title>
</info>
+
<para><anchor xml:id="dbdoclet.50438203_pgfId-999824" xreflabel=""/>This chapter describes some tools for managing Lustre Networking (LNET) and includes the following sections:</para>
<itemizedlist><listitem>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1286381" xreflabel=""/><link xl:href="ManagingLNET.html#50438203_51732">Updating the Health Status of a Peer or Router</link></para>
- </listitem>
-<listitem>
- <para> </para>
- </listitem>
-<listitem>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1287154" xreflabel=""/><link xl:href="ManagingLNET.html#50438203_48703">Starting and Stopping LNET</link></para>
- </listitem>
-<listitem>
- <para> </para>
- </listitem>
-<listitem>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1289983" xreflabel=""/><link xl:href="ManagingLNET.html#50438203_82542">Multi-Rail Configurations with LNET</link></para>
- </listitem>
-<listitem>
- <para> </para>
- </listitem>
-<listitem>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1290404" xreflabel=""/><link xl:href="ManagingLNET.html#50438203_78227">Load Balancing with InfiniBand</link></para>
- </listitem>
-<listitem>
- <para> </para>
- </listitem>
-</itemizedlist>
- <section remap="h2">
- <title><anchor xml:id="dbdoclet.50438203_pgfId-1289878" xreflabel=""/></title>
- <section remap="h2">
- <title>15.1 <anchor xml:id="dbdoclet.50438203_51732" xreflabel=""/>Updating the Health Status of a Peer or <anchor xml:id="dbdoclet.50438203_marker-1288828" xreflabel=""/>Router</title>
+ <para><xref linkend="50438203_51732"/>Updating the Health Status of a Peer or Router</para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="50438203_48703"/>Starting and Stopping LNET</para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="50438203_82542"/>Multi-Rail Configurations with LNET</para>
+ </listitem>
+ <listitem>
+ <para><xref linkend="50438203_78227"/>Load Balancing with InfiniBand</para>
+ </listitem>
+ </itemizedlist>
+
+ <section xml:id="dbdoclet.50438203_51732">
+ <title>15.1 Updating the Health Status of a Peer or <anchor xml:id="dbdoclet.50438203_marker-1288828" xreflabel=""/>Router</title>
<para><anchor xml:id="dbdoclet.50438203_pgfId-1287380" xreflabel=""/>There are two mechanisms to update the health status of a peer or a router:</para>
<itemizedlist><listitem>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1287381" xreflabel=""/> LNET can actively check health status of all routers and mark them as dead or alive automatically. By default, this is off. To enable it set auto_down and if desired check_routers_before_use. This initial check may cause a pause equal to router_ping_timeout at system startup, if there are dead routers in the system.</para>
+ <para><anchor xml:id="dbdoclet.50438203_pgfId-1287381" xreflabel=""/>LNET can actively check health status of all routers and mark them as dead or alive automatically. By default, this is off. To enable it set auto_down and if desired check_routers_before_use. This initial check may cause a pause equal to router_ping_timeout at system startup, if there are dead routers in the system.</para>
</listitem>
<listitem>
- <para> </para>
- </listitem>
-<listitem>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1287382" xreflabel=""/> When there is a communication error, all LNDs notify LNET that the peer (not necessarily a router) is down. This mechanism is always on, and there is no parameter to turn it off. However, if you set the LNET module parameter auto_down to 0, LNET ignores all such peer-down notifications.</para>
- </listitem>
-<listitem>
- <para> </para>
+ <para><anchor xml:id="dbdoclet.50438203_pgfId-1287382" xreflabel=""/>When there is a communication error, all LNDs notify LNET that the peer (not necessarily a router) is down. This mechanism is always on, and there is no parameter to turn it off. However, if you set the LNET module parameter auto_down to 0, LNET ignores all such peer-down notifications.</para>
</listitem>
</itemizedlist>
<para><anchor xml:id="dbdoclet.50438203_pgfId-1287383" xreflabel=""/>Several key differences in both mechanisms:</para>
<itemizedlist><listitem>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1287384" xreflabel=""/> The router pinger only checks routers for their health, while LNDs notices all dead peers, regardless of whether they are a router or not.</para>
- </listitem>
-<listitem>
- <para> </para>
- </listitem>
-<listitem>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1287385" xreflabel=""/> The router pinger actively checks the router health by sending pings, but LNDs only notice a dead peer when there is network traffic going on.</para>
+ <para><anchor xml:id="dbdoclet.50438203_pgfId-1287384" xreflabel=""/>The router pinger only checks routers for their health, while LNDs notices all dead peers, regardless of whether they are a router or not.</para>
</listitem>
<listitem>
- <para> </para>
+ <para><anchor xml:id="dbdoclet.50438203_pgfId-1287385" xreflabel=""/>The router pinger actively checks the router health by sending pings, but LNDs only notice a dead peer when there is network traffic going on.</para>
</listitem>
<listitem>
<para><anchor xml:id="dbdoclet.50438203_pgfId-1287386" xreflabel=""/> The router pinger can bring a router from alive to dead or vice versa, but LNDs can only bring a peer down.</para>
</listitem>
-<listitem>
- <para> </para>
- </listitem>
</itemizedlist>
</section>
- <section remap="h2">
- <title>15.2 <anchor xml:id="dbdoclet.50438203_48703" xreflabel=""/>Starting and Stopping LNET</title>
+ <section xml:id="dbdoclet.50438203_48703">
+ <title>15.2 Starting and Stopping LNET</title>
<para><anchor xml:id="dbdoclet.50438203_pgfId-1287399" xreflabel=""/>Lustre automatically starts and stops LNET, but it can also be manually started in a standalone manner. This is particularly useful to verify that your networking setup is working correctly before you attempt to start Lustre.</para>
<section remap="h3">
<title><anchor xml:id="dbdoclet.50438203_pgfId-1287402" xreflabel=""/>15.2.1 Starting <anchor xml:id="dbdoclet.50438203_marker-1287400" xreflabel=""/>LNET</title>
<para><anchor xml:id="dbdoclet.50438203_pgfId-1287480" xreflabel=""/>Before the LNET modules can be removed, LNET references must be removed. In general, these references are removed automatically when Lustre is shut down, but for standalone routers, an explicit step is needed to stop LNET. Run:</para>
<screen><anchor xml:id="dbdoclet.50438203_pgfId-1287481" xreflabel=""/>lctl network unconfigure
</screen>
- <informaltable frame="none">
- <tgroup cols="1">
- <colspec colname="c1" colwidth="100*"/>
- <tbody>
- <row>
- <entry><para><emphasis role="bold">Note -</emphasis><anchor xml:id="dbdoclet.50438203_pgfId-1287482" xreflabel=""/>Attempting to remove Lustre modules prior to stopping the network may result in a crash or an LNET hang. if this occurs, the node must be rebooted (in most cases). Make sure that the Lustre network and Lustre are stopped prior to unloading the modules. Be extremely careful using rmmod -f.</para></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
+
+<note>
+ <para>
+Attempting to remove Lustre modules prior to stopping the network may result in a crash or an LNET hang. if this occurs, the node must be rebooted (in most cases). Make sure that the Lustre network and Lustre are stopped prior to unloading the modules. Be extremely careful using rmmod -f.</para>
+</note>
+
<para><anchor xml:id="dbdoclet.50438203_pgfId-1287486" xreflabel=""/>To unconfigure the LNET network, run:</para>
<screen><anchor xml:id="dbdoclet.50438203_pgfId-1287487" xreflabel=""/>modprobe -r <any lnd and the lnet modules>
</screen>
- <informaltable frame="none">
- <tgroup cols="1">
- <colspec colname="c1" colwidth="100*"/>
- <tbody>
- <row>
- <entry><para><emphasis role="bold">Tip -</emphasis><anchor xml:id="dbdoclet.50438203_pgfId-1287488" xreflabel=""/>To remove all Lustre modules, run:</para><para>$ lctl modules | awk '{print $2}' | xargs rmmod</para></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
+
+<note>
+ <para>
+To remove all Lustre modules, run:</para><para>$ lctl modules | awk '{print $2}' | xargs rmmod</para>
+</note>
+
+
</section>
</section>
- <section remap="h2">
- <title>15.3 <anchor xml:id="dbdoclet.50438203_
72197" xreflabel=""/><anchor xml:id="dbdoclet.50438203_82542" xreflabel=""/>Multi-Rail Configurations with <anchor xml:id="dbdoclet.50438203_Multi-rail-configurations-with-LNET-LNET" xreflabel=""/>LNET</title>
+ <section xml:id="dbdoclet.50438203_72197">
+ <title>15.3 <anchor xml:id="dbdoclet.50438203_82542" xreflabel=""/>Multi-Rail Configurations with <anchor xml:id="dbdoclet.50438203_Multi-rail-configurations-with-LNET-LNET" xreflabel=""/>LNET</title>
<para><anchor xml:id="dbdoclet.50438203_pgfId-1289933" xreflabel=""/>To aggregate bandwidth across both rails of a dual-rail IB cluster (o2iblnd) <footnote><para><anchor xml:id="dbdoclet.50438203_pgfId-1289932" xreflabel=""/>Multi-rail configurations are only supported by o2iblnd; other IB LNDs do not support multiple interfaces.</para></footnote> using LNET, consider these points:</para>
<itemizedlist><listitem>
<para><anchor xml:id="dbdoclet.50438203_pgfId-1289934" xreflabel=""/> LNET can work with multiple rails, however, it does not load balance across them. The actual rail used for any communication is determined by the peer NID.</para>
</listitem>
<listitem>
- <para> </para>
- </listitem>
-<listitem>
<para><anchor xml:id="dbdoclet.50438203_pgfId-1289935" xreflabel=""/> Multi-rail LNET configurations do not provide an additional level of network fault tolerance. The configurations described below are for bandwidth aggregation only. Network interface failover is planned as an upcoming Lustre feature.</para>
</listitem>
<listitem>
- <para> </para>
- </listitem>
-<listitem>
<para><anchor xml:id="dbdoclet.50438203_pgfId-1289936" xreflabel=""/> A Lustre node always uses the same local NID to communicate with a given peer NID. The criteria used to determine the local NID are:</para>
- </listitem>
-<listitem>
<itemizedlist><listitem>
<para><anchor xml:id="dbdoclet.50438203_pgfId-1289937" xreflabel=""/> Fewest hops (to minimize routing), and</para>
</listitem>
<listitem>
- <para> </para>
- </listitem>
-<listitem>
<para><anchor xml:id="dbdoclet.50438203_pgfId-1289938" xreflabel=""/> Appears first in the "networks" or "ip2nets" LNET configuration strings</para>
</listitem>
-<listitem>
- <para> </para>
- </listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</section>
- <section remap="h2">
- <title>15.4 <anchor xml:id="dbdoclet.50438203_78227" xreflabel=""/>Load Balancing with InfiniBand</title>
+ <section xml:id="dbdoclet.50438203_78227">
+ <title>15.4 Load Balancing with InfiniBand</title>
<para><anchor xml:id="dbdoclet.50438203_pgfId-1290370" xreflabel=""/>A Lustre file system contains OSSs with two InfiniBand HCAs. Lustre clients have only one InfiniBand HCA using OFED Infiniband ''o2ib'' drivers. Load balancing between the HCAs on the OSS is accomplished through LNET.</para>
<section remap="h3">
<title><anchor xml:id="dbdoclet.50438203_pgfId-1290317" xreflabel=""/>15.4.1 Setting Up modprobe.conf<anchor xml:id="dbdoclet.50438203_77834" xreflabel=""/><anchor xml:id="dbdoclet.50438203_marker-1290316" xreflabel=""/> for Load Balancing</title>
<itemizedlist><listitem>
<para><anchor xml:id="dbdoclet.50438203_pgfId-1290321" xreflabel=""/> Dual HCA OSS server</para>
</listitem>
-<listitem>
- <para> </para>
- </listitem>
</itemizedlist>
<screen><anchor xml:id="dbdoclet.50438203_pgfId-1290322" xreflabel=""/>options lnet networks="o2ib0(ib0),o2ib1(ib1) 192.168.10.1.[101-102]
</screen>
<itemizedlist><listitem>
<para><anchor xml:id="dbdoclet.50438203_pgfId-1290323" xreflabel=""/> Client with the odd IP address</para>
</listitem>
-<listitem>
- <para> </para>
- </listitem>
</itemizedlist>
<screen><anchor xml:id="dbdoclet.50438203_pgfId-1290324" xreflabel=""/>options lnet networks=o2ib0(ib0) 192.168.10.[103-253/2]
</screen>
<itemizedlist><listitem>
<para><anchor xml:id="dbdoclet.50438203_pgfId-1290325" xreflabel=""/> Client with the even IP address</para>
</listitem>
-<listitem>
- <para> </para>
- </listitem>
</itemizedlist>
<screen><anchor xml:id="dbdoclet.50438203_pgfId-1290326" xreflabel=""/>options lnet networks=o2ib1(ib0) 192.168.10.[102-254/2]
</screen>
<itemizedlist><listitem>
<para><anchor xml:id="dbdoclet.50438203_pgfId-1289944" xreflabel=""/> A cluster with more clients than servers. The fact that an individual client cannot get two rails of bandwidth is unimportant because the servers are the actual bottleneck.</para>
</listitem>
-<listitem>
- <para> </para>
- </listitem>
</itemizedlist>
<screen><anchor xml:id="dbdoclet.50438203_pgfId-1289945" xreflabel=""/>ip2nets="o2ib0(ib0), o2ib1(ib1) 192.168.[0-1].* \
#all servers;\
<itemizedlist><listitem>
<para><anchor xml:id="dbdoclet.50438203_pgfId-1289949" xreflabel=""/> A single client that must get two rails of bandwidth, and it does not matter if the maximum aggregate bandwidth is only (# servers) * (1 rail).</para>
</listitem>
-<listitem>
- <para> </para>
- </listitem>
</itemizedlist>
<screen><anchor xml:id="dbdoclet.50438203_pgfId-1289950" xreflabel=""/>ip2nets=" o2ib0(ib0) 192.168.[0-1].[0-252/2] \
#even servers;\
<itemizedlist><listitem>
<para><anchor xml:id="dbdoclet.50438203_pgfId-1289954" xreflabel=""/> All clients and all servers must get two rails of bandwidth.</para>
</listitem>
-<listitem>
- <para> </para>
- </listitem>
</itemizedlist>
<screen><anchor xml:id="dbdoclet.50438203_pgfId-1289955" xreflabel=""/>ip2nets=†o2ib0(ib0),o2ib2(ib1) 192.168.[0-1].[0-252/2] \
#even servers;\
</screen>
<para><anchor xml:id="dbdoclet.50438203_pgfId-1289959" xreflabel=""/>This configuration includes two additional proxy o2ib networks to work around Lustre's simplistic NID selection algorithm. It connects "even" clients to "even" servers with o2ib0 on rail0, and "odd" servers with o2ib3 on rail1. Similarly, it connects "odd" clients to "odd" servers with o2ib1 on rail0, and "even" servers with o2ib2 on rail1.</para>
</section>
- </section>
</section>
</chapter>
git://git.whamcloud.com / doc / manual.git / blobdiff