connection.txt

   1 Connections Between Lustre Entities
   2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   3 [[connection]]
   4
   5 The Lustre protocol is connection-based in that each two entities
   6 maintain shared, coordinated state information. The most common
   7 example is the connection between a client and the target on some
   8 server. The target is identified by name to the client through an
   9 interaction with the management server. The client then 'connects' to
  10 the given target on the indicated server by sending the appropriate
  11 version of the various *_CONNECT messages (MGS_CONNECT, MDS_CONNECT,
  12 or OST_CONNECT) and receiving back the corresponding *_CONNECT
  13 reply. The server creates an 'export' (See <<struct-obd-export>>) for
  14 the connection between the target and the client, and the export holds
  15 the server state information for that connection. When the client gets
  16 the reply it creates an 'import' (See <<struct-obd-import>>), and the
  17 import holds the client state information for that connection. Note
  18 that if a server has N targets and M clients have connected to them,
  19 the server will have N x M exports and each client will have N
  20 imports.
  21
  22 There are also connections between the servers: Each MDS and OSS has a
  23 connection to the MGS, where the MDS (respectively the OSS) plays the
  24 role of the client in the above discussion. That is, the MDS initiates
  25 the connection and has an import for the MGS, while the MGS has an
  26 export for each MDS. Each MDS creates an 'object storage proxy' (OSP)
  27 connection to each OST, with an import on the MDS and an export on the
  28 OSS. This connection supports requests from the MDS to the OST to
  29 create and destroy data objects, to set attributes (such as permission
  30 bits), and for 'statfs' information for precreation needs.  Each OSS
  31 also connects to the first MDS to get access to auxiliary services,
  32 with an import on the OSS and an export on the first MDS.  The
  33 auxiliary services are: the File ID Location Database (FLDB), the
  34 quota master service, and the sequence controller. This connection for
  35 auxiliary services is a 'light weight proxy' (LWP) connection in that
  36 it has no replay functionality (See <<recovery>>) and consumes no
  37 space on the MDS for client data. Each MDS also connects to all other
  38 MDSs for DNE needs.
  39
  40 Finally, for some communications the roles of message initiation and
  41 message reply are reversed. This is the case, for instance, with
  42 call-back operations. In that case the entity which would normally
  43 have an import has, instead, a 'reverse-export' and the
  44 other end of the connection maintains a 'reverse-import'. The
  45 reverse-import uses the same structure as a regular import, and the
  46 reverse-export uses the same structure as a regular export.
  47
  48 include::struct_obd_connect_data.txt[]
  49
  50 include::struct_obd_import.txt[]
  51
  52 include::struct_obd_export.txt[]
  53
  54 include::timeouts.txt[]
  55
  56 include::eviction.txt[]
  57
  58 include::recovery.txt[]
  59