ManagingLNET.xml

   1 <?xml version='1.0' encoding='UTF-8'?>
   2 <!-- This document was created with Syntext Serna Free. -->
   3 <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">
   4   <info>
   5     <title xml:id="managinglnet.title">Managing Lustre Networking (LNET)</title>
   6   </info>
   7   <para>This chapter describes some tools for managing Lustre Networking (LNET) and includes the following sections:</para>
   8   <itemizedlist>
   9     <listitem>
  10       <para><xref linkend="dbdoclet.50438203_51732"/></para>
  11     </listitem>
  12     <listitem>
  13       <para><xref linkend="dbdoclet.50438203_48703"/></para>
  14     </listitem>
  15     <listitem>
  16       <para><xref linkend="dbdoclet.50438203_82542"/></para>
  17     </listitem>
  18     <listitem>
  19       <para><xref linkend="dbdoclet.50438203_78227"/></para>
  20     </listitem>
  21   </itemizedlist>
  22   <section xml:id="dbdoclet.50438203_51732">
  23     <title>15.1 Updating the Health Status of a Peer or Router</title>
  24     <para>There are two mechanisms to update the health status of a peer or a router:</para>
  25     <itemizedlist>
  26       <listitem>
  27         <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>
  28       </listitem>
  29       <listitem>
  30         <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>
  31       </listitem>
  32     </itemizedlist>
  33     <para>Several key differences in both mechanisms:</para>
  34     <itemizedlist>
  35       <listitem>
  36         <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>
  37       </listitem>
  38       <listitem>
  39         <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>
  40       </listitem>
  41       <listitem>
  42         <para> The router pinger can bring a router from alive to dead or vice versa, but LNDs can only bring a peer down.</para>
  43       </listitem>
  44     </itemizedlist>
  45   </section>
  46   <section xml:id="dbdoclet.50438203_48703">
  47     <title>15.2 Starting and Stopping LNET</title>
  48     <para>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>
  49     <section remap="h3">
  50       <title>15.2.1 Starting LNET</title>
  51       <para>To start LNET, run:</para>
  52       <screen>$ modprobe lnet
  53 $ lctl network up</screen>
  54       <para>To see the list of local NIDs, run:</para>
  55       <screen>$ lctl list_nids</screen>
  56       <para>This command tells you the network(s) configured to work with Lustre</para>
  57       <para>If the networks are not correctly setup, see the <literal>modules.conf</literal> &quot;<literal>networks=</literal>&quot; line and make sure the network layer modules are correctly installed and configured.</para>
  58       <para>To get the best remote NID, run:</para>
  59       <screen>$ lctl which_nid &lt;NID list&gt;</screen>
  60       <para>where <literal>&lt;NID list&gt;</literal> is the list of available NIDs.</para>
  61       <para>This command takes the &quot;best&quot; NID from a list of the NIDs of a remote host. The &quot;best&quot; NID is the one that the local node uses when trying to communicate with the remote node.</para>
  62       <section remap="h4">
  63         <title>15.2.1.1 Starting Clients</title>
  64         <para>To start a TCP client, run:</para>
  65         <screen>mount -t lustre mdsnode:/mdsA/client /mnt/lustre/</screen>
  66         <para>To start an Elan client, run:</para>
  67         <screen>mount -t lustre 2@elan0:/mdsA/client /mnt/lustre</screen>
  68       </section>
  69     </section>
  70     <section remap="h3">
  71       <title>15.2.2 Stopping LNET</title>
  72       <para>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>
  73       <screen>lctl network unconfigure</screen>
  74       <note>
  75         <para>
  76 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>
  77       </note>
  78       <para>To unconfigure the LNET network, run:</para>
  79       <screen>modprobe -r &lt;any lnd and the lnet modules&gt;
  80 </screen>
  81       <note>
  82         <para>
  83 To remove all Lustre modules, run:</para>
  84         <para><literal>$ lctl modules | awk &apos;{print $2}&apos; | xargs rmmod</literal></para>
  85       </note>
  86     </section>
  87   </section>
  88   <section xml:id="dbdoclet.50438203_82542">
  89     <title>15.3 Multi-Rail Configurations with LNET</title>
  90     <para>To aggregate bandwidth across both rails of a dual-rail IB cluster (o2iblnd) <footnote>
  91         <para>Multi-rail configurations are only supported by o2iblnd; other IB LNDs do not support multiple interfaces.</para>
  92       </footnote> using LNET, consider these points:</para>
  93     <itemizedlist>
  94       <listitem>
  95         <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>
  96       </listitem>
  97       <listitem>
  98         <para>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>
  99       </listitem>
 100       <listitem>
 101         <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>
 102         <itemizedlist>
 103           <listitem>
 104             <para> Fewest hops (to minimize routing), and</para>
 105           </listitem>
 106           <listitem>
 107             <para> Appears first in the &quot;<literal>networks</literal>&quot; or &quot;<literal>ip2nets</literal>&quot; LNET configuration strings</para>
 108           </listitem>
 109         </itemizedlist>
 110       </listitem>
 111     </itemizedlist>
 112   </section>
 113   <section xml:id="dbdoclet.50438203_78227">
 114     <title>15.4 Load Balancing with InfiniBand</title>
 115     <para>A Lustre file system contains OSSs with two InfiniBand HCAs. Lustre clients have only one InfiniBand HCA using OFED Infiniband &apos;&apos;o2ib&apos;&apos; drivers. Load balancing between the HCAs on the OSS is accomplished through LNET.</para>
 116     <section remap="h3">
 117       <title>15.4.1 Setting Up <literal>modprobe.conf</literal> for Load Balancing</title>
 118       <para>To configure LNET for load balancing on clients and servers:</para>
 119       <orderedlist>
 120         <listitem>
 121           <para><emphasis role="bold">Set the <literal>modprobe.conf</literal> options.</emphasis></para>
 122           <para>Depending on your configuration, set modprobe.conf options as follows:</para>
 123           <itemizedlist>
 124             <listitem>
 125               <para> Dual HCA OSS server</para>
 126             </listitem>
 127           </itemizedlist>
 128           <screen>options lnet networks=&quot;o2ib0(ib0),o2ib1(ib1) 192.168.10.1.[101-102] </screen>
 129           <itemizedlist>
 130             <listitem>
 131               <para> Client with the odd IP address</para>
 132             </listitem>
 133           </itemizedlist>
 134           <screen>options lnet networks=o2ib0(ib0) 192.168.10.[103-253/2] </screen>
 135           <itemizedlist>
 136             <listitem>
 137               <para> Client with the even IP address</para>
 138             </listitem>
 139           </itemizedlist>
 140           <screen>options lnet networks=o2ib1(ib0) 192.168.10.[102-254/2]
 141 </screen>
 142         </listitem>
 143         <listitem>
 144           <para><emphasis role="bold">Run the modprobe lnet command and create a combined MGS/MDT file system.</emphasis></para>
 145           <para>The following commands create the MGS/MDT file system and mount the servers (MGS/MDT and OSS).</para>
 146           <screen>modprobe lnet
 147 $ mkfs.lustre --fsname lustre --mgs --mdt &lt;block device name&gt;
 148 $ mkdir -p &lt;mount point&gt;
 149 $ mount -t lustre &lt;block device&gt; &lt;mount point&gt;
 150 $ mount -t lustre &lt;block device&gt; &lt;mount point&gt;
 151 $ mkfs.lustre --fsname lustre --mgs --mdt &lt;block device name&gt;
 152 $ mkdir -p &lt;mount point&gt;
 153 $ mount -t lustre &lt;block device&gt; &lt;mount point&gt;
 154 $ mount -t lustre &lt;block device&gt; &lt;mount point&gt; </screen>
 155           <para>For example:</para>
 156           <screen>modprobe lnet
 157 $ mkfs.lustre --fsname lustre --mdt --mgs /dev/sda
 158 $ mkdir -p /mnt/test/mdt
 159 $ mount -t lustre /dev/sda /mnt/test/mdt
 160 $ mount -t lustre mgs@o2ib0:/lustre /mnt/mdt
 161 $ mkfs.lustre --fsname lustre --ost --mgsnode=mds@o2ib0 /dev/sda
 162 $ mkdir -p /mnt/test/mdt
 163 $ mount -t lustre /dev/sda /mnt/test/ost
 164 $ mount -t lustre mgs@o2ib0:/lustre /mnt/ost</screen>
 165         </listitem>
 166         <listitem>
 167           <para><emphasis role="bold">Mount the clients.</emphasis></para>
 168           <screen>mount -t lustre &lt;MGS node&gt;:/&lt;fsname&gt; &lt;mount point&gt;</screen>
 169           <para>This example shows an IB client being mounted.</para>
 170           <screen>mount -t lustre
 171 192.168.10.101@o2ib0,192.168.10.102@o2ib1:/mds/client /mnt/lustre</screen>
 172         </listitem>
 173       </orderedlist>
 174       <para>As an example, consider a two-rail IB cluster running the OFA stack (OFED) with these IPoIB address assignments.</para>
 175       <screen>             ib0                             ib1
 176 Servers            192.168.0.*                     192.168.1.*
 177 Clients            192.168.[2-127].*               192.168.[128-253].*</screen>
 178       <para>You could create these configurations:</para>
 179       <itemizedlist>
 180         <listitem>
 181           <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 the actual bottleneck.</para>
 182         </listitem>
 183       </itemizedlist>
 184       <screen>ip2nets=&quot;o2ib0(ib0),    o2ib1(ib1)      192.168.[0-1].*                     \
 185                                             #all servers;\
 186                    o2ib0(ib0)      192.168.[2-253].[0-252/2]       #even cl\
 187 ients;\
 188                    o2ib1(ib1)      192.168.[2-253].[1-253/2]       #odd cli\
 189 ents&quot;</screen>
 190       <para>This configuration gives every server two NIDs, one on each network, and statically load-balances clients between the rails.</para>
 191       <itemizedlist>
 192         <listitem>
 193           <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>
 194         </listitem>
 195       </itemizedlist>
 196       <screen>ip2nets=&quot;       o2ib0(ib0)                      192.168.[0-1].[0-252/2]     \
 197                                             #even servers;\
 198            o2ib1(ib1)                      192.168.[0-1].[1-253/2]         \
 199                                         #odd servers;\
 200            o2ib0(ib0),o2ib1(ib1)           192.168.[2-253].*               \
 201                                         #clients&quot;</screen>
 202       <para>This configuration gives every server a single NID on one rail or the other. Clients have a NID on both rails.</para>
 203       <itemizedlist>
 204         <listitem>
 205           <para> All clients and all servers must get two rails of bandwidth.</para>
 206         </listitem>
 207       </itemizedlist>
 208       <screen>ip2nets=â€   o2ib0(ib0),o2ib2(ib1)           192.168.[0-1].[0-252/2]       \
 209   #even servers;\
 210            o2ib1(ib0),o2ib3(ib1)           192.168.[0-1].[1-253/2]         \
 211 #odd servers;\
 212            o2ib0(ib0),o2ib3(ib1)           192.168.[2-253].[0-252/2)       \
 213 #even clients;\
 214            o2ib1(ib0),o2ib2(ib1)           192.168.[2-253].[1-253/2)       \
 215 #odd clients&quot;
 216 </screen>
 217       <para>This configuration includes two additional proxy o2ib networks to work around Lustre&apos;s simplistic NID selection algorithm. It connects &quot;even&quot; clients to &quot;even&quot; servers with <literal>o2ib0</literal> on <literal>rail0</literal>, and &quot;odd&quot; servers with <literal>o2ib3</literal> on <literal>rail1</literal>. Similarly, it connects &quot;odd&quot; clients to &quot;odd&quot; servers with <literal>o2ib1</literal> on <literal>rail0</literal>, and &quot;even&quot; servers with <literal>o2ib2</literal> on <literal>rail1</literal>.</para>
 218     </section>
 219   </section>
 220 </chapter>