Client Sessions

../_images/RMR_Arch-Client_1.png

The diagram shows a compute client (psrv1) hosting four RMR pools across four storage nodes. Each pool has a replication factor of 2, giving 8 pool sessions in total. Yet only 4 RTRS sessions exist — one per unique storage node.

Pool sessions and client sessions

RMR separates the concept of a replication leg from the concept of an RTRS connection into two distinct structures.

rmr_clt_pool_sess is the replication leg. Each pool has one pool_sess per storage node it replicates to. It carries per-pool state: IO routing, dirty map tracking, and session state (NORMAL, FAILED, RECONNECTING, etc.).

rmr_clt_sess is the shared RTRS connection to a storage node. It is identified by session name (e.g. psrv1@rmr-srv1) and maintained in a global list. A pool_sess does not own an RTRS connection directly — it holds a reference to a clt_sess and uses it to send IO and command messages.

Why the split

RTRS pre-allocates and pre-maps memory on the storage server side when a session is established. With a one-pool-one-device design, a compute client hosting many pools would create one RTRS session per pool per storage node. The memory cost on the storage side scales with the number of pools, not the number of storage nodes.

By separating pool_sess from clt_sess, pools that replicate to the same storage node share a single RTRS session. In the diagram, pools 1 and 3 both have a leg to rmr-srv1; they share the psrv1@rmr-srv1 clt_sess and the single RTRS session beneath it. The number of RTRS sessions is bounded by the number of unique storage nodes, not the number of pools.