-<?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">
- <info>
- <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>
+<?xml version='1.0' encoding='UTF-8'?><chapter xmlns="http://docbook.org/ns/docbook" xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en-US" xml:id="managinglnet">
+ <title xml:id="managinglnet.title">Managing Lustre Networking (LNET)</title>
+ <para>This chapter describes some tools for managing Lustre networking (LNET) and includes the
+ following sections:</para>
+ <itemizedlist>
+ <listitem>
+ <para><xref linkend="dbdoclet.50438203_51732"/></para>
</listitem>
-<listitem>
- <para> </para>
+ <listitem>
+ <para><xref linkend="dbdoclet.50438203_48703"/></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>
+ <para><xref linkend="dbdoclet.50438203_82542"/></para>
</listitem>
-<listitem>
- <para> </para>
+ <listitem>
+ <para><xref linkend="dbdoclet.50438203_78227"/></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>
+ <para><xref linkend="managinglnet.configuringroutes"/></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><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>
- </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>
- </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>
- </listitem>
-<listitem>
- <para> </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>
- <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-1287403" xreflabel=""/>To start LNET, run:</para>
- <screen><anchor xml:id="dbdoclet.50438203_pgfId-1287404" xreflabel=""/>$ modprobe lnet
-<anchor xml:id="dbdoclet.50438203_pgfId-1287405" xreflabel=""/>$ lctl network up
-</screen>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1287406" xreflabel=""/>To see the list of local NIDs, run:</para>
- <screen><anchor xml:id="dbdoclet.50438203_pgfId-1287407" xreflabel=""/>$ lctl list_nids
-</screen>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1289144" xreflabel=""/>This command tells you the network(s) configured to work with Lustre</para>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1287409" xreflabel=""/>If the networks are not correctly setup, see the modules.conf "networks=" line and make sure the network layer modules are correctly installed and configured.</para>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1287410" xreflabel=""/>To get the best remote NID, run:</para>
- <screen><anchor xml:id="dbdoclet.50438203_pgfId-1287411" xreflabel=""/>$ lctl which_nid <NID list>
-</screen>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1287412" xreflabel=""/>where <NID list> is the list of available NIDs.</para>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1287413" xreflabel=""/>This command takes the "best" NID from a list of the NIDs of a remote host. The "best" NID is the one that the local node uses when trying to communicate with the remote node.</para>
- <section remap="h4">
- <title><anchor xml:id="dbdoclet.50438203_pgfId-1287415" xreflabel=""/>15.2.1.1 <anchor xml:id="dbdoclet.50438203_46145" xreflabel=""/>Starting Clients</title>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1287416" xreflabel=""/>To start a TCP client, run:</para>
- <screen><anchor xml:id="dbdoclet.50438203_pgfId-1287417" xreflabel=""/>mount -t lustre mdsnode:/mdsA/client /mnt/lustre/
-</screen>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1287418" xreflabel=""/>To start an Elan client, run:</para>
- <screen><anchor xml:id="dbdoclet.50438203_pgfId-1287419" xreflabel=""/>mount -t lustre 2@elan0:/mdsA/client /mnt/lustre
-</screen>
- </section>
- </section>
- <section remap="h3">
- <title><anchor xml:id="dbdoclet.50438203_pgfId-1287473" xreflabel=""/>15.2.2 Stopping <anchor xml:id="dbdoclet.50438203_marker-1288543" 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>
- <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>
+ </itemizedlist>
+ <section xml:id="dbdoclet.50438203_51732">
+ <title><indexterm><primary>LNET</primary><secondary>management</secondary></indexterm>
+ Updating the Health Status of a Peer or Router</title>
+ <para>There are two mechanisms to update the health status of a peer or a router:</para>
+ <itemizedlist>
+ <listitem>
+ <para>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 <literal>auto_down</literal> and if desired <literal>check_routers_before_use</literal>. This initial check may cause a pause equal to <literal>router_ping_timeout</literal> at system startup, if there are dead routers in the system.</para>
+ </listitem>
+ <listitem>
+ <para>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 <literal>auto_down</literal> to <literal>0</literal>, LNET ignores all such peer-down notifications.</para>
+ </listitem>
+ </itemizedlist>
+ <para>Several key differences in both mechanisms:</para>
+ <itemizedlist>
+ <listitem>
+ <para>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>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>The router pinger can bring a router from alive to dead or vice versa, but LNDs can only bring a peer down.</para>
+ </listitem>
+ </itemizedlist>
+ </section>
+ <section xml:id="dbdoclet.50438203_48703">
+ <title><indexterm><primary>LNET</primary><secondary>starting/stopping</secondary></indexterm>Starting and Stopping LNET</title>
+ <para>The Lustre software 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 the Lustre file system.</para>
+ <section remap="h3">
+ <title>Starting LNET</title>
+ <para>To start LNET, run:</para>
+ <screen>$ modprobe lnet
+$ lctl network up</screen>
+ <para>To see the list of local NIDs, run:</para>
+ <screen>$ lctl list_nids</screen>
+ <para>This command tells you the network(s) configured to work with the Lustre file
+ system.</para>
+ <para>If the networks are not correctly setup, see the <literal>modules.conf</literal> "<literal>networks=</literal>" line and make sure the network layer modules are correctly installed and configured.</para>
+ <para>To get the best remote NID, run:</para>
+ <screen>$ lctl which_nid <replaceable>NIDs</replaceable></screen>
+ <para>where <literal><replaceable>NIDs</replaceable></literal> is the list of available NIDs.</para>
+ <para>This command takes the "best" NID from a list of the NIDs of a remote host. The "best" NID is the one that the local node uses when trying to communicate with the remote node.</para>
+ <section remap="h4">
+ <title>Starting Clients</title>
+ <para>To start a TCP client, run:</para>
+ <screen>mount -t lustre mdsnode:/mdsA/client /mnt/lustre/</screen>
+ <para>To start an Elan client, run:</para>
+ <screen>mount -t lustre 2@elan0:/mdsA/client /mnt/lustre</screen>
</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>
- <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>
+ <section remap="h3">
+ <title>Stopping LNET</title>
+ <para>Before the LNET modules can be removed, LNET references must be removed. In general,
+ these references are removed automatically when the Lustre file system is shut down, but for
+ standalone routers, an explicit step is needed to stop LNET. Run:</para>
+ <screen>lctl network unconfigure</screen>
+ <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 file system are stopped prior to unloading the
+ modules. Be extremely careful using <literal>rmmod -f</literal>.</para>
+ </note>
+ <para>To unconfigure the LNET network, run:</para>
+ <screen>modprobe -r <replaceable>lnd_and_lnet_modules</replaceable></screen>
+ <note>
+ <para>
+To remove all Lustre modules, run:</para>
+ <para><literal>$ lustre_rmmod</literal></para>
+ </note>
+ </section>
+ </section>
+ <section xml:id="dbdoclet.50438203_82542">
+ <title><indexterm><primary>LNET</primary><secondary>multi-rail configuration</secondary></indexterm>Multi-Rail Configurations with LNET</title>
+ <para>To aggregate bandwidth across both rails of a dual-rail IB cluster (o2iblnd) <footnote>
+ <para>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>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>Multi-rail LNET configurations do not provide an additional level of network fault
+ tolerance. The configurations described below are for bandwidth aggregation only. </para>
+ </listitem>
+ <listitem>
+ <para>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>
+ <itemizedlist>
+ <listitem>
+ <para condition='l25'>Lowest route priority number (lower number, higher priority).</para>
+ </listitem>
+ <listitem>
+ <para>Fewest hops (to minimize routing), and</para>
+ </listitem>
+ <listitem>
+ <para>Appears first in the "<literal>networks</literal>" or "<literal>ip2nets</literal>" LNET configuration strings</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </itemizedlist>
+ </section>
+ <section xml:id="dbdoclet.50438203_78227">
+ <title><indexterm>
+ <primary>LNET</primary>
+ <secondary>InfiniBand load balancing</secondary>
+ </indexterm>Load Balancing with an InfiniBand<superscript>*</superscript> Network</title>
+ <para>A Lustre file system contains OSSs with two InfiniBand HCAs. Lustre clients have only one
+ InfiniBand HCA using OFED-based Infiniband ''o2ib'' drivers. Load
+ balancing between the HCAs on the OSS is accomplished through LNET.</para>
+ <section remap="h3">
+ <title><indexterm><primary>LNET</primary><secondary>lustre.conf</secondary></indexterm>Setting Up <literal>lustre.conf</literal> for Load Balancing</title>
+ <para>To configure LNET for load balancing on clients and servers:</para>
+ <orderedlist>
+ <listitem>
+ <para>Set the <literal>lustre.conf</literal> options.</para>
+ <para>Depending on your configuration, set <literal>lustre.conf</literal> options as follows:</para>
+ <itemizedlist>
+ <listitem>
+ <para>Dual HCA OSS server</para>
</listitem>
-<listitem>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1289938" xreflabel=""/> Appears first in the "networks" or "ip2nets" LNET configuration strings</para>
+ </itemizedlist>
+ <screen>options lnet networks="o2ib0(ib0),o2ib1(ib1)"</screen>
+ <itemizedlist>
+ <listitem>
+ <para>Client with the odd IP address</para>
</listitem>
-<listitem>
- <para> </para>
+ </itemizedlist>
+ <screen>options lnet ip2nets="o2ib0(ib0) 192.168.10.[103-253/2]"</screen>
+ <itemizedlist>
+ <listitem>
+ <para>Client with the even IP address</para>
</listitem>
-</itemizedlist>
+ </itemizedlist>
+ <screen>options lnet ip2nets="o2ib1(ib0) 192.168.10.[102-254/2]"</screen>
</listitem>
-</itemizedlist>
- </section>
- <section remap="h2">
- <title>15.4 <anchor xml:id="dbdoclet.50438203_78227" xreflabel=""/>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>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1290318" xreflabel=""/>To configure LNET for load balancing on clients and servers:</para>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1290319" xreflabel=""/> 1. Set the modprobe.conf options.</para>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1290320" xreflabel=""/>Depending on your configuration, set modprobe.conf options as follows:</para>
- <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>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1290327" xreflabel=""/> 2. Run the modprobe lnet command and create a combined MGS/MDT file system.</para>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1290328" xreflabel=""/>The following commands create the MGS/MDT file system and mount the servers (MGS/MDT and OSS).</para>
- <screen><anchor xml:id="dbdoclet.50438203_pgfId-1290329" xreflabel=""/>modprobe lnet
-<anchor xml:id="dbdoclet.50438203_pgfId-1290330" xreflabel=""/>$ mkfs.lustre --fsname lustre --mgs --mdt <block device name>
-<anchor xml:id="dbdoclet.50438203_pgfId-1290331" xreflabel=""/>$ mkdir -p <mount point>
-<anchor xml:id="dbdoclet.50438203_pgfId-1290332" xreflabel=""/>$ mount -t lustre <block device> <mount point>
-<anchor xml:id="dbdoclet.50438203_pgfId-1290333" xreflabel=""/>$ mount -t lustre <block device> <mount point>
-<anchor xml:id="dbdoclet.50438203_pgfId-1290334" xreflabel=""/>$ mkfs.lustre --fsname lustre --mgs --mdt <block device name>
-<anchor xml:id="dbdoclet.50438203_pgfId-1290335" xreflabel=""/>$ mkdir -p <mount point>
-<anchor xml:id="dbdoclet.50438203_pgfId-1290336" xreflabel=""/>$ mount -t lustre <block device> <mount point>
-<anchor xml:id="dbdoclet.50438203_pgfId-1290337" xreflabel=""/>$ mount -t lustre <block device> <mount point>
-</screen>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1290338" xreflabel=""/>For example:</para>
- <screen><anchor xml:id="dbdoclet.50438203_pgfId-1290339" xreflabel=""/>modprobe lnet
-<anchor xml:id="dbdoclet.50438203_pgfId-1290340" xreflabel=""/>$ mkfs.lustre --fsname lustre --mdt --mgs /dev/sda
-<anchor xml:id="dbdoclet.50438203_pgfId-1290341" xreflabel=""/>$ mkdir -p /mnt/test/mdt
-<anchor xml:id="dbdoclet.50438203_pgfId-1290342" xreflabel=""/>$ mount -t lustre /dev/sda /mnt/test/mdt
-<anchor xml:id="dbdoclet.50438203_pgfId-1290343" xreflabel=""/>$ mount -t lustre mgs@o2ib0:/lustre /mnt/mdt
-<anchor xml:id="dbdoclet.50438203_pgfId-1290344" xreflabel=""/>$ mkfs.lustre --fsname lustre --ost --mgsnode=mds@o2ib0 /dev/sda
-<anchor xml:id="dbdoclet.50438203_pgfId-1290345" xreflabel=""/>$ mkdir -p /mnt/test/mdt
-<anchor xml:id="dbdoclet.50438203_pgfId-1290346" xreflabel=""/>$ mount -t lustre /dev/sda /mnt/test/ost
-<anchor xml:id="dbdoclet.50438203_pgfId-1290347" xreflabel=""/>$ mount -t lustre mgs@o2ib0:/lustre /mnt/ost
-</screen>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1290348" xreflabel=""/> 3. Mount the clients.</para>
- <screen><anchor xml:id="dbdoclet.50438203_pgfId-1290349" xreflabel=""/>mount -t lustre <MGS node>:/<fsname> <mount point>
-</screen>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1290350" xreflabel=""/>This example shows an IB client being mounted.</para>
- <screen><anchor xml:id="dbdoclet.50438203_pgfId-1290351" xreflabel=""/>mount -t lustre
-<anchor xml:id="dbdoclet.50438203_pgfId-1290352" xreflabel=""/>192.168.10.101@o2ib0,192.168.10.102@o2ib1:/mds/client /mnt/lustre
-</screen>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1289939" xreflabel=""/>As an example, consider a two-rail IB cluster running the OFA stack (OFED) with these IPoIB address assignments.</para>
- <screen><anchor xml:id="dbdoclet.50438203_pgfId-1289940" xreflabel=""/> ib0 ib1
-<anchor xml:id="dbdoclet.50438203_pgfId-1289941" xreflabel=""/>Servers 192.168.0.* 192.168.1.*
-<anchor xml:id="dbdoclet.50438203_pgfId-1289942" xreflabel=""/>Clients 192.168.[2-127].* 192.168.[128-253].*
-</screen>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1289943" xreflabel=""/>You could create these configurations:</para>
- <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].* \
+ <listitem>
+ <para>Run the modprobe lnet command and create a combined MGS/MDT file system.</para>
+ <para>The following commands create an MGS/MDT or OST file system and mount the targets on the servers.</para>
+ <screen>modprobe lnet
+# mkfs.lustre --fsname lustre --mgs --mdt <replaceable>/dev/mdt_device</replaceable>
+# mkdir -p <replaceable>/mount_point</replaceable>
+# mount -t lustre /dev/<replaceable>mdt_device</replaceable> <replaceable>/mount_point</replaceable></screen>
+ <para>For example:</para>
+ <screen>modprobe lnet
+mds# mkfs.lustre --fsname lustre --mdt --mgs /dev/sda
+mds# mkdir -p /mnt/test/mdt
+mds# mount -t lustre /dev/sda /mnt/test/mdt
+mds# mount -t lustre mgs@o2ib0:/lustre /mnt/mdt
+oss# mkfs.lustre --fsname lustre --mgsnode=mds@o2ib0 --ost --index=0 /dev/sda
+oss# mkdir -p /mnt/test/mdt
+oss# mount -t lustre /dev/sda /mnt/test/ost
+oss# mount -t lustre mgs@o2ib0:/lustre /mnt/ost0</screen>
+ </listitem>
+ <listitem>
+ <para>Mount the clients.</para>
+ <screen>client# mount -t lustre <replaceable>mgs_node</replaceable>:/<replaceable>fsname</replaceable> <replaceable>/mount_point</replaceable></screen>
+ <para>This example shows an IB client being mounted.</para>
+ <screen>client# mount -t lustre
+192.168.10.101@o2ib0,192.168.10.102@o2ib1:/mds/client /mnt/lustre</screen>
+ </listitem>
+ </orderedlist>
+ <para>As an example, consider a two-rail IB cluster running the OFED stack with these IPoIB
+ address assignments.</para>
+ <screen> ib0 ib1
+Servers 192.168.0.* 192.168.1.*
+Clients 192.168.[2-127].* 192.168.[128-253].*</screen>
+ <para>You could create these configurations:</para>
+ <itemizedlist>
+ <listitem>
+ <para>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 typically the actual bottleneck.</para>
+ </listitem>
+ </itemizedlist>
+ <screen>ip2nets="o2ib0(ib0), o2ib1(ib1) 192.168.[0-1].* \
#all servers;\
-<anchor xml:id="dbdoclet.50438203_pgfId-1289946" xreflabel=""/> o2ib0(ib0) 192.168.[2-253].[0-252/2] #even cl\
+ o2ib0(ib0) 192.168.[2-253].[0-252/2] #even cl\
ients;\
-<anchor xml:id="dbdoclet.50438203_pgfId-1289947" xreflabel=""/> o2ib1(ib1) 192.168.[2-253].[1-253/2] #odd cli\
-ents"
-</screen>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1289948" xreflabel=""/>This configuration gives every server two NIDs, one on each network, and statically load-balances clients between the rails.</para>
- <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] \
+ o2ib1(ib1) 192.168.[2-253].[1-253/2] #odd cli\
+ents"</screen>
+ <para>This configuration gives every server two NIDs, one on each network, and statically load-balances clients between the rails.</para>
+ <itemizedlist>
+ <listitem>
+ <para>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>
+ </itemizedlist>
+ <screen>ip2nets=" o2ib0(ib0) 192.168.[0-1].[0-252/2] \
#even servers;\
-<anchor xml:id="dbdoclet.50438203_pgfId-1289951" xreflabel=""/> o2ib1(ib1) 192.168.[0-1].[1-253/2] \
+ o2ib1(ib1) 192.168.[0-1].[1-253/2] \
#odd servers;\
-<anchor xml:id="dbdoclet.50438203_pgfId-1289952" xreflabel=""/> o2ib0(ib0),o2ib1(ib1) 192.168.[2-253].* \
- #clients"
-</screen>
- <para><anchor xml:id="dbdoclet.50438203_pgfId-1289953" xreflabel=""/>This configuration gives every server a single NID on one rail or the other. Clients have a NID on both rails.</para>
- <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] \
+ o2ib0(ib0),o2ib1(ib1) 192.168.[2-253].* \
+ #clients"</screen>
+ <para>This configuration gives every server a single NID on one rail or the other. Clients have a NID on both rails.</para>
+ <itemizedlist>
+ <listitem>
+ <para>All clients and all servers must get two rails of bandwidth.</para>
+ </listitem>
+ </itemizedlist>
+ <screen>ip2nets=†o2ib0(ib0),o2ib2(ib1) 192.168.[0-1].[0-252/2] \
#even servers;\
-<anchor xml:id="dbdoclet.50438203_pgfId-1289956" xreflabel=""/> o2ib1(ib0),o2ib3(ib1) 192.168.[0-1].[1-253/2] \
+ o2ib1(ib0),o2ib3(ib1) 192.168.[0-1].[1-253/2] \
#odd servers;\
-<anchor xml:id="dbdoclet.50438203_pgfId-1289957" xreflabel=""/> o2ib0(ib0),o2ib3(ib1) 192.168.[2-253].[0-252/2) \
+ o2ib0(ib0),o2ib3(ib1) 192.168.[2-253].[0-252/2) \
#even clients;\
-<anchor xml:id="dbdoclet.50438203_pgfId-1289958" xreflabel=""/> o2ib1(ib0),o2ib2(ib1) 192.168.[2-253].[1-253/2) \
-#odd clients"
-</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>
+ o2ib1(ib0),o2ib2(ib1) 192.168.[2-253].[1-253/2) \
+#odd clients"</screen>
+ <para>This configuration includes two additional proxy o2ib networks to work around the
+ simplistic NID selection algorithm in the Lustre software. It connects "even"
+ clients to "even" servers with <literal>o2ib0</literal> on
+ <literal>rail0</literal>, and "odd" servers with <literal>o2ib3</literal> on
+ <literal>rail1</literal>. Similarly, it connects "odd" clients to
+ "odd" servers with <literal>o2ib1</literal> on <literal>rail0</literal>, and
+ "even" servers with <literal>o2ib2</literal> on <literal>rail1</literal>.</para>
+ </section>
+ </section>
+ <section xml:id="managinglnet.configuringroutes" condition='l24'>
+ <title><indexterm><primary>LNET</primary></indexterm>Dynamically Configuring LNET Routes</title>
+ <para>Two scripts are provided: <literal>lustre/scripts/lustre_routes_config</literal> and <literal>lustre/scripts/lustre_routes_conversion</literal>.</para>
+ <para><literal>lustre_routes_config</literal> sets or cleans up LNET routes from the specified config file. <literal>/etc/sysconfig/lustre_routes.conf</literal> file can be used to automatically configure routes on LNET startup. </para>
+ <para><literal>lustre_routes_conversion</literal> converts a legacy routes configuration file to the new syntax, which is parsed by <literal>lustre_routes_config</literal>.</para>
+ <section remap="h3">
+ <title><indexterm><primary>LNET</primary></indexterm><literal>lustre_routes_config</literal></title>
+ <para><literal>lustre_routes_config</literal> usage is as follows</para>
+ <screen><literal>lustre_routes_config [--setup|--cleanup|--dry-run|--verbose] <replaceable>config_file</replaceable></literal>
+ --setup: configure routes listed in config_file
+ --cleanup: unconfigure routes listed in config_file
+ --dry-run: echo commands to be run, but do not execute them
+ --verbose: echo commands before they are executed </screen>
+ <para> The format of the file which is passed into the script is as follows: </para>
+ <para><literal><replaceable>network</replaceable>: { gateway: <replaceable>gateway</replaceable>@<replaceable>exit_network</replaceable> [hop: <replaceable>hop</replaceable>] [priority: <replaceable>priority</replaceable>] }</literal></para>
+ <para> An LNET router is identified when its local NID appears within the list of routes. However, this can not be achieved by the use of this script, since the script only adds extra routes after the router is identified. To ensure that a router is identified correctly, make sure to add its local NID in the routes parameter in the modprobe lustre configuration file. See <xref linkend='dbdoclet.50438293_15350'/>.</para>
+ </section>
+ <section remap="h3">
+ <title><indexterm><primary>LNET</primary></indexterm><literal>lustre_routes_conversion</literal></title>
+ <para><literal>lustre_routes_conversion</literal> usage is as follows:</para>
+ <screen><literal>lustre_routes_conversion <replaceable>legacy_file</replaceable> <replaceable>new_file</replaceable></literal></screen>
+ <para><literal>lustre_routes_conversion</literal> takes as a first parameter a file with routes configured as follows:</para>
+ <para><literal><replaceable>network</replaceable> [<replaceable>hop</replaceable>] <replaceable>gateway</replaceable>@<replaceable>exit network</replaceable>[:<replaceable>priority</replaceable>];</literal></para>
+ <para>The script then converts each routes entry in the provided file to:</para>
+ <para><literal><replaceable>network</replaceable>: { gateway: <replaceable>gateway</replaceable>@<replaceable>exit network</replaceable> [hop: <replaceable>hop</replaceable>] [priority: <replaceable>priority</replaceable>] }</literal></para>
+ <para>and appends each converted entry to the output file passed in as the second parameter to the script.</para>
+ </section>
+ <section remap="h3">
+ <title><indexterm><primary>LNET</primary></indexterm><literal>Route Configuration Examples</literal></title>
+ <para>Below is an example of a legacy LNET route configuration. A legacy configuration file can have multiple entries.</para>
+ <screen><literal>tcp1 10.1.1.2@tcp0:1;
+tcp2 10.1.1.3@tcp0:2;
+tcp3 10.1.1.4@tcp0;</literal></screen>
+ <para>Below is an example of the converted LNET route configuration. The following would be the result of the <literal>lustre_routes_conversion</literal> script, when run on the above legacy entries.</para>
+ <screen><literal>tcp1: { gateway: 10.1.1.2@tcp0 priority: 1 }
+tcp2: { gateway: 10.1.1.2@tcp0 priority: 2 }
+tcp1: { gateway: 10.1.1.4@tcp0 }</literal></screen>
</section>
</section>
</chapter>
git://git.whamcloud.com / doc / manual.git / blobdiff