LNetMultiRail.xml

   1 <?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="lnetmr" condition='l210'>
   2   <title xml:id="lnetmr.title">LNet Software Multi-Rail</title>
   3   <para>This chapter describes LNet Software Multi-Rail configuration and
   4   administration.</para>
   5   <itemizedlist>
   6     <listitem>
   7       <para><xref linkend="dbdoclet.mroverview"/></para>
   8       <para><xref linkend="dbdoclet.mrconfiguring"/></para>
   9       <para><xref linkend="dbdoclet.mrrouting"/></para>
  10     </listitem>
  11   </itemizedlist>
  12   <section xml:id="dbdoclet.mroverview">
  13     <title><indexterm><primary>MR</primary><secondary>overview</secondary>
  14     </indexterm>Multi-Rail Overview</title>
  15     <para>In computer networking, multi-rail is an arrangement in which two or
  16     more network interfaces to a single network on a computer node are employed,
  17     to achieve increased throughput.  Multi-rail can also be where a node has
  18     one or more interfaces to multiple, even different kinds of networks, such
  19     as Ethernet, Infiniband, and Intel® Omni-Path. For Lustre clients,
  20     multi-rail generally presents the combined network capabilities as a single
  21     LNet network.  Peer nodes that are multi-rail capable are established during
  22     configuration, as are user-defined interface-section policies.</para>
  23     <para>The following link contains a detailed high-level design for the
  24     feature:
  25     <link xl:href="http://wiki.lustre.org/images/b/bb/Multi-Rail_High-Level_Design_20150119.pdf">
  26     Multi-Rail High-Level Design</link></para>
  27   </section>
  28   <section xml:id="dbdoclet.mrconfiguring">
  29       <title><indexterm><primary>MR</primary><secondary>configuring</secondary>
  30       </indexterm>Configuring Multi-Rail</title>
  31       <para>Every node using multi-rail networking needs to be properly
  32       configured.  Multi-rail uses <literal>lnetctl</literal> and the LNet
  33       Configuration Library for configuration.  Configuring multi-rail for a
  34       given node involves two tasks:</para>
  35       <orderedlist>
  36         <listitem><para>Configuring multiple network interfaces present on the
  37         local node.</para></listitem>
  38         <listitem><para>Adding remote peers that are multi-rail capable (are
  39         connected to one or more common networks with at least two interfaces).
  40         </para></listitem>
  41       </orderedlist>
  42       <para>This section is a supplement to
  43           <xref linkend="lnet_config.lnetaddshowdelete" /> and contains further
  44           examples for Multi-Rail configurations.</para>
  45       <para>For information on the dynamic peer discovery feature added in
  46         Lustre Release 2.11.0, see
  47         <xref linkend="lnet_config.dynamic_discovery" />.</para>
  48       <section xml:id="dbdoclet.addinterfaces">
  49           <title><indexterm><primary>MR</primary>
  50           <secondary>multipleinterfaces</secondary>
  51           </indexterm>Configure Multiple Interfaces on the Local Node</title>
  52           <para>Example <literal>lnetctl add</literal> command with multiple
  53           interfaces in a Multi-Rail configuration:</para>
  54           <screen>lnetctl net add --net tcp --if eth0,eth1</screen>
  55           <para>Example of YAML net show:</para>
  56           <screen>lnetctl net show -v
  57 net:
  58     - net type: lo
  59       local NI(s):
  60         - nid: 0@lo
  61           status: up
  62           statistics:
  63               send_count: 0
  64               recv_count: 0
  65               drop_count: 0
  66           tunables:
  67               peer_timeout: 0
  68               peer_credits: 0
  69               peer_buffer_credits: 0
  70               credits: 0
  71           lnd tunables:
  72           tcp bonding: 0
  73           dev cpt: 0
  74           CPT: "[0]"
  75     - net type: tcp
  76       local NI(s):
  77         - nid: 192.168.122.10@tcp
  78           status: up
  79           interfaces:
  80               0: eth0
  81           statistics:
  82               send_count: 0
  83               recv_count: 0
  84               drop_count: 0
  85           tunables:
  86               peer_timeout: 180
  87               peer_credits: 8
  88               peer_buffer_credits: 0
  89               credits: 256
  90           lnd tunables:
  91           tcp bonding: 0
  92           dev cpt: -1
  93           CPT: "[0]"
  94         - nid: 192.168.122.11@tcp
  95           status: up
  96           interfaces:
  97               0: eth1
  98           statistics:
  99               send_count: 0
 100               recv_count: 0
 101               drop_count: 0
 102           tunables:
 103               peer_timeout: 180
 104               peer_credits: 8
 105               peer_buffer_credits: 0
 106               credits: 256
 107           lnd tunables:
 108           tcp bonding: 0
 109           dev cpt: -1
 110           CPT: "[0]"</screen>
 111       </section>
 112       <section xml:id="dbdoclet.deleteinterfaces">
 113           <title><indexterm><primary>MR</primary>
 114               <secondary>deleteinterfaces</secondary>
 115           </indexterm>Deleting Network Interfaces</title>
 116           <para>Example delete with <literal>lnetctl net del</literal>:</para>
 117           <para>Assuming the network configuration is as shown above with the
 118           <literal>lnetctl net show -v</literal> in the previous section, we can
 119           delete a net with following command:</para>
 120           <screen>lnetctl net del --net tcp --if eth0</screen>
 121           <para>The resultant net information would look like:</para>
 122           <screen>lnetctl net show -v
 123 net:
 124     - net type: lo
 125       local NI(s):
 126         - nid: 0@lo
 127           status: up
 128           statistics:
 129               send_count: 0
 130               recv_count: 0
 131               drop_count: 0
 132           tunables:
 133               peer_timeout: 0
 134               peer_credits: 0
 135               peer_buffer_credits: 0
 136               credits: 0
 137           lnd tunables:
 138           tcp bonding: 0
 139           dev cpt: 0
 140           CPT: "[0,1,2,3]"</screen>
 141           <para>The syntax of a YAML file to perform a delete would be:</para>
 142           <screen>- net type: tcp
 143    local NI(s):
 144      - nid: 192.168.122.10@tcp
 145        interfaces:
 146            0: eth0</screen>
 147       </section>
 148       <section xml:id="dbdoclet.addremotepeers">
 149           <title><indexterm><primary>MR</primary>
 150               <secondary>addremotepeers</secondary>
 151           </indexterm>Adding Remote Peers that are Multi-Rail Capable</title>
 152           <para>The following example <literal>lnetctl peer add</literal>
 153           command adds a peer with 2 nids, with
 154           <literal>192.168.122.30@tcp</literal> being the primary nid:</para>
 155           <screen>lnetctl peer add --prim_nid 192.168.122.30@tcp --nid 192.168.122.30@tcp,192.168.122.31@tcp
 156           </screen>
 157           <para>The resulting <literal>lnetctl peer show</literal> would be:
 158           <screen>lnetctl peer show -v
 159 peer:
 160     - primary nid: 192.168.122.30@tcp
 161       Multi-Rail: True
 162       peer ni:
 163         - nid: 192.168.122.30@tcp
 164           state: NA
 165           max_ni_tx_credits: 8
 166           available_tx_credits: 8
 167           min_tx_credits: 7
 168           tx_q_num_of_buf: 0
 169           available_rtr_credits: 8
 170           min_rtr_credits: 8
 171           refcount: 1
 172           statistics:
 173               send_count: 2
 174               recv_count: 2
 175               drop_count: 0
 176         - nid: 192.168.122.31@tcp
 177           state: NA
 178           max_ni_tx_credits: 8
 179           available_tx_credits: 8
 180           min_tx_credits: 7
 181           tx_q_num_of_buf: 0
 182           available_rtr_credits: 8
 183           min_rtr_credits: 8
 184           refcount: 1
 185           statistics:
 186               send_count: 1
 187               recv_count: 1
 188               drop_count: 0</screen>
 189           </para>
 190           <para>The following is an example YAML file for adding a peer:</para>
 191           <screen>addPeer.yaml
 192 peer:
 193     - primary nid: 192.168.122.30@tcp
 194       Multi-Rail: True
 195       peer ni:
 196         - nid: 192.168.122.31@tcp</screen>
 197       </section>
 198       <section xml:id="dbdoclet.deleteremotepeers">
 199           <title><indexterm><primary>MR</primary>
 200               <secondary>deleteremotepeers</secondary>
 201           </indexterm>Deleting Remote Peers</title>
 202           <para>Example of deleting a single nid of a peer (192.168.122.31@tcp):
 203           </para>
 204           <screen>lnetctl peer del --prim_nid 192.168.122.30@tcp --nid 192.168.122.31@tcp</screen>
 205           <para>Example of deleting the entire peer:</para>
 206           <screen>lnetctl peer del --prim_nid 192.168.122.30@tcp</screen>
 207           <para>Example of deleting a peer via YAML:</para>
 208           <screen>Assuming the following peer configuration:
 209 peer:
 210     - primary nid: 192.168.122.30@tcp
 211       Multi-Rail: True
 212       peer ni:
 213         - nid: 192.168.122.30@tcp
 214           state: NA
 215         - nid: 192.168.122.31@tcp
 216           state: NA
 217         - nid: 192.168.122.32@tcp
 218           state: NA
 219
 220 You can delete 192.168.122.32@tcp as follows:
 221
 222 delPeer.yaml
 223 peer:
 224     - primary nid: 192.168.122.30@tcp
 225       Multi-Rail: True
 226       peer ni:
 227         - nid: 192.168.122.32@tcp
 228
 229 % lnetctl import --del &lt; delPeer.yaml</screen>
 230       </section>
 231   </section>
 232   <section xml:id="dbdoclet.mrrouting">
 233       <title><indexterm><primary>MR</primary>
 234           <secondary>mrrouting</secondary>
 235       </indexterm>Notes on routing with Multi-Rail</title>
 236       <para>Multi-Rail configuration can be applied on the Router to aggregate
 237       the interfaces performance.</para>
 238       <section xml:id="dbdoclet.mrroutingex">
 239           <title><indexterm><primary>MR</primary>
 240               <secondary>mrrouting</secondary>
 241               <tertiary>routingex</tertiary>
 242           </indexterm>Multi-Rail Cluster Example</title>
 243       <para>The below example outlines a simple system where all the Lustre
 244       nodes are MR capable.  Each node in the cluster has two interfaces.</para>
 245       <figure xml:id="lnetmultirail.fig.routingdiagram">
 246           <title>Routing Configuration with Multi-Rail</title>
 247           <mediaobject>
 248           <imageobject>
 249               <imagedata scalefit="1" width="100%"
 250               fileref="./figures/MR_RoutingConfig.png" />
 251           </imageobject>
 252           <textobject>
 253                <phrase>Routing Configuration with Multi-Rail</phrase>
 254           </textobject>
 255           </mediaobject>
 256       </figure>
 257       <para>The routers can aggregate the interfaces on each side of the network
 258       by configuring them on the appropriate network.</para>
 259       <para>An example configuration:</para>
 260       <screen>Routers
 261 lnetctl net add --net o2ib0 --if ib0,ib1
 262 lnetctl net add --net o2ib1 --if ib2,ib3
 263 lnetctl peer add --nid &lt;peer1-nidA&gt;@o2ib,&lt;peer1-nidB&gt;@o2ib,...
 264 lnetctl peer add --nid &lt;peer2-nidA&gt;@o2ib1,&lt;peer2-nidB>&gt;@o2ib1,...
 265 lnetctl set routing 1
 266
 267 Clients
 268 lnetctl net add --net o2ib0 --if ib0,ib1
 269 lnetctl route add --net o2ib1 --gateway &lt;rtrX-nidA&gt;@o2ib
 270 lnetctl peer add --nid &lt;rtrX-nidA&gt;@o2ib,&lt;rtrX-nidB&gt;@o2ib
 271
 272 Servers
 273 lnetctl net add --net o2ib1 --if ib0,ib1
 274 lnetctl route add --net o2ib0 --gateway &lt;rtrX-nidA&gt;@o2ib1
 275 lnetctl peer add --nid &lt;rtrX-nidA&gt;@o2ib1,&lt;rtrX-nidB&gt;@o2ib1</screen>
 276       <para>In the above configuration the clients and the servers are
 277       configured with only one route entry per router. This works because the
 278       routers are MR capable. By adding the routers as peers with multiple
 279       interfaces to the clients and the servers, when sending to the router the
 280       MR algorithm will ensure that bot interfaces of the routers are used.
 281       </para>
 282       <para>However, as of the Lustre 2.10 release LNet Resiliency is still
 283       under development and single interface failure will still cause the entire
 284       router to go down.</para>
 285       </section>
 286       <section xml:id="dbdoclet.mrroutingresiliency">
 287           <title><indexterm><primary>MR</primary>
 288               <secondary>mrrouting</secondary>
 289               <tertiary>routingresiliency</tertiary>
 290           </indexterm>Utilizing Router Resiliency</title>
 291       <para>Currently, LNet provides a mechanism to monitor each route entry.
 292       LNet pings each gateway identified in the route entry on regular,
 293       configurable interval to ensure that it is alive. If sending over a
 294       specific route fails or if the router pinger determines that the gateway
 295       is down, then the route is marked as down and is not used. It is
 296       subsequently pinged on regular, configurable intervals to determine when
 297       it becomes alive again.</para>
 298       <para>This mechanism can be combined with the MR feature in Lustre 2.10 to
 299       add this router resiliency feature to the configuration.</para>
 300       <screen>Routers
 301 lnetctl net add --net o2ib0 --if ib0,ib1
 302 lnetctl net add --net o2ib1 --if ib2,ib3
 303 lnetctl peer add --nid &lt;peer1-nidA&gt;@o2ib,&lt;peer1-nidB&gt;@o2ib,...
 304 lnetctl peer add --nid &lt;peer2-nidA&gt;@o2ib1,&lt;peer2-nidB&gt;@o2ib1,...
 305 lnetctl set routing 1
 306
 307 Clients
 308 lnetctl net add --net o2ib0 --if ib0,ib1
 309 lnetctl route add --net o2ib1 --gateway &lt;rtrX-nidA&gt;@o2ib
 310 lnetctl route add --net o2ib1 --gateway &lt;rtrX-nidB&gt;@o2ib
 311
 312 Servers
 313 lnetctl net add --net o2ib1 --if ib0,ib1
 314 lnetctl route add --net o2ib0 --gateway &lt;rtrX-nidA&gt;@o2ib1
 315 lnetctl route add --net o2ib0 --gateway &lt;rtrX-nidB&gt;@o2ib1</screen>
 316       <para>There are a few things to note in the above configuration:</para>
 317       <orderedlist>
 318           <listitem>
 319               <para>The clients and the servers are now configured with two
 320               routes, each route's gateway is one of the interfaces of the
 321               route.  The clients and servers will view each interface of the
 322               same router as a separate gateway and will monitor them as
 323               described above.</para>
 324           </listitem>
 325           <listitem>
 326               <para>The clients and the servers are not configured to view the
 327               routers as MR capable. This is important because we want to deal
 328               with each interface as a separate peers and not different
 329               interfaces of the same peer.</para>
 330           </listitem>
 331           <listitem>
 332               <para>The routers are configured to view the peers as MR capable.
 333               This is an oddity in the configuration, but is currently required
 334               in order to allow the routers to load balance the traffic load
 335               across its interfaces evenly.</para>
 336           </listitem>
 337         </orderedlist>
 338       </section>
 339       <section xml:id="dbdoclet.mrroutingmixed">
 340           <title><indexterm><primary>MR</primary>
 341               <secondary>mrrouting</secondary>
 342               <tertiary>routingmixed</tertiary>
 343           </indexterm>Mixed Multi-Rail/Non-Multi-Rail Cluster</title>
 344           <para>The above principles can be applied to mixed MR/Non-MR cluster.
 345           For example, the same configuration shown above can be applied if the
 346           clients and the servers are non-MR while the routers are MR capable.
 347           This appears to be a common cluster upgrade scenario.</para>
 348       </section>
 349   </section>
 350 </chapter>