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 of two such entities are a client and a 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 *_CONNECT message (MGS_CONNECT, MDS_CONNECT, or
  12 OST_CONNECT - colectively *_CONNECT) and receiving back the
  13 corresponding *_CONNECT reply. The server creates an 'export' for the
  14 connection between the target and the client, and the export holds the
  15 server state information for that connection. When the client gets the
  16 reply it creates an 'import', and the import holds the client state
  17 information for that connection. Note that if a server has N targets
  18 and M clients have connected to them, the server will have N x M
  19 exports and each client will have N imports.
  20
  21 There are also connections between the servers: Each MDS and OSS has a
  22 connection to the MGS, where the MDS (respectively the OSS) plays the
  23 role of the client in the above discussion. That is, the MDS initiates
  24 the connection and has an import for the MGS, while the MGS has an
  25 export for each MDS. Each MDS connects to each OST, with an import on
  26 the MDS and an export on the OSS. This connection supports requests
  27 from the MDS to the OST to create and destroy data objects, to set
  28 attributes (such as permission bits), and for 'statfs' information for
  29 precreation needs.  Each OSS also connects to the first MDS to get
  30 access to auxiliary services, with an import on the OSS and an export
  31 on the first MDS.  The auxiliary services are: the File ID Location
  32 Database (FLDB), the quota master service, and the sequence
  33 controller. This connection for auxiliary services is a 'lightweight'
  34 one in that it has no replay functionality and consumes no space on
  35 the MDS for client data. Each MDS connects also to all other MDSs for
  36 DNE needs.
  37
  38 Finally, for some communications the roles of message initiation and
  39 message reply are reversed. This is the case, for instance, with
  40 call-back operations. In that case the entity which would normally
  41 have an import has, instead, a 'reverse-export' and the
  42 other end of the connection maintains a 'reverse-import'. The
  43 reverse-import uses the same structure as a regular import, and the
  44 reverse-export uses the same structure as a regular export.
  45
  46 #################################################################
  47 Fixme: Move the obd_connect_data.txt include to where it first
  48 gets introduced. Perhaps in obd_connect_client.txt?
  49 #################################################################
  50
  51 include::obd_connect_data.txt[]
  52
  53 include::import.txt[]
  54
  55 include::export.txt[]
  56
  57 include::timeouts.txt[]
  58
  59 include::eviction.txt[]
  60
  61 include::recovery.txt[]
  62