OpenFAM 3.0 Services

OpenFAM version 2.0 introduced the concept of supporitng large pool of memory using multiple memory servers. OpenFAM version 3.0 contains significant design changes to increase scalability and improve performance.

The design supports a larger pool of memory by supporting multiple memory servers. This memory pool can be either volatile or persistent.
Data can be interleaved as data items can now span across multiple memory servers, thus reducing performance bottlenecks.
Datapath operations can now be partitioned into multiple contexts.
Multi-threaded data path and atomic operations are supported.
Additional APIs have been added to the facilitate data movement between memory pool and archival storage.

Figure 1: OpenFAM Memory server components

Figure 1 shows the three main components in the design.

The client interface service (CIS):: All PEs talk to the CIS for memory server operations.
The metadata management service:: Region and data item metadata is hosted by the metadata management service. The service can be co-located in the same node as a CIS server or a memory server, or it can be run in dedicated metadata management nodes.
The memory management service:: The actual memory is served from memory servers. For data path (get, put and atomic) operations PEs talk to the memory servers directly. For memory management and metadata operations, e.g., allocate, lookup, create_region, etc., the CIS communicates with memory servers via an RPC service or via direct functions calls.

The services communicate with one another using grpc calls. However, as an optimization, if the components are compiled into the same executable, they bypass grpc and use direct function calls for communication. Yaml-based configuration files determine how the services are configured.

See configuration and startup of OpenFAM 3.0 services in the Configuration Files section.