Memverge, Inc.

California Institute of Technology

Other

Seagate Technology Incorporated

The Texas A&m University System

Yue Li

Robert W Beauchamp

Ronald S Niles

Jehoshua Bruck

Jie Yu

Chenggong Charles Fan

Jun Gan

Erich Franz Haratsch

Abdelhakim Alhussien

Eyal En Gad

Yue Zhao

Ning Xu

Wei Kang

Anxiao Jiang

Jiajie Sun

Kunwu Huang

Yuanjie Wu

Haiyan Wang

Michael Langberg

Chenggong Fan

Dahong Li

Earl T Cohen

Yu Cai

Ivana Djurdjevic

Xin Liang Li

Peiyu Zhuang

Wentao Huang

Yong Tian

Srinivas Aji

Joerg Kliewer

Ashley Tung

Jingchao Sun

To address loss of access to computing instances in a cloud computing environment, techniques are introduced for moving an application between computing instances in the cloud computing environment. A computing service captures baseline or delta snapshots of the state of the application running on a first computing instance. A baseline snapshot is indicative of the full state of the application, and a delta snapshot is indicative of changes in the state since a most recent snapshot was captured. Responsive to receiving an indication that the first computing instance is to stop servicing the application, the computing service stops the application from running on the first computing instance and moves data from the captured snapshots to a second computing instance. The computing service resume execution of the application on the second computing instances and captures snapshots of the state of the application at the second computing instance.

Efficiency and reliability improvement in computing service

A memory image can be captured by generating metadata indicative of a state of volatile memory and/or byte-addressable PMEM at a particular time during execution of a process by an application. This memory image can be persisted without copying the in-memory data into a separate persistent storage by storing the metadata and safekeeping the in-memory data in the volatile memory and/or PMEM. Metadata associated with multiple time-evolved memory images captured can be stored and managed using a linked index scheme. A linked index scheme can be configured in various ways including a full index and a difference-only index. The memory images can be used for various purposes including suspending and later resuming execution of the application process, restoring a failed application to a previous point in time, cloning an application, and recovering an application process to a most recent state in an application log.

Memory image capture

Reduced impact application recovery

A technique is introduced for applying multi-level caching to deploy various types of physical memory to service captured memory calls from an application. The various types of physical memory can include local volatile memory (e.g., dynamic random-access memory), local persistent memory, and/or remote persistent memory. In an example embodiment, a user-space page fault notification mechanism is used to defer assignment of actual physical memory resources until a memory buffer is accessed by the application. After populating a selected physical memory in response to an initial user-space page fault notification, page access information can be monitored to determine which pages continues to be accessed and which pages are inactive to identify candidates for eviction.

Multi-level caching to deploy local volatile memory, local persistent memory, and remote persistent memory

Application recovery using a memory image

Persistent memory image capture

A technique is described for handling forks in operations mapped to direct access persistent memory (PMEM). In an example embodiment, access by a parent operation of an allocated portion of PMEM is monitored to determine a portion of the allocated PMEM that is in use by the parent operation. In response to a fork call indicating that the parent operation will copy itself to create a child operation, a clone of the portion of allocated PMEM is created to facilitate processing of the child operation. The cloned portion of PMEM can be created just before the child operation is created (i.e., pre-fork) or after the child operation is created (i.e., post-fork). To create the clone post-fork, a user-space page fault notification mechanism can be implemented to detect a next buffer access by the child operation and create the clone in response to the detected access.

Fork handling in application operations mapped to direct access persistent memory

A technique is introduced for intercepting memory calls from a user-space application and applying an allocation policy to determine whether such calls are handled using volatile memory such as dynamic random-access memory (DRAM) or persistent memory (PMEM). In an example embodiment, memory calls from an application are intercepted by a memory allocation capture library. Such calls may be to a memory function such as malloc( ) and may be configured to cause a portion of DRAM to be allocated to the application to process a task. The memory allocation capture library then determines whether the intercepted call satisfies capture criteria associated with an allocation policy. If the intercepted call does satisfy the capture criteria, the call is processed to cause a portion of PMEM to be allocated to the application instead of DRAM.

Applying an allocation policy to capture memory calls using a memory allocation capture library

Disclosed herein is an apparatus and method for a naming service in a distributed memory object system. In one embodiment, a name service method includes electing a primary node for the master key value store from a plurality of name service nodes, the primary node to receive master key value requests, a master key value store containing an entry for each directory within the distributed memory object, wherein the master key value store is configured for associating a directory pathname to a uniform unique identifier, and replicating the master key value store across the plurality of name service nodes. In another embodiment, a name service computing device includes a primary node for the master key value store, wherein the primary node is selected from a plurality of name service nodes and is configured to receive master key value requests, a master key value store containing an entry for each directory within the distributed memory object, wherein the master key value store is configured to associate a directory pathname to a uniform unique identifier, and the system further being in communication with the plurality of name service nodes, wherein the master key value store is replicated across the plurality of name service nodes.

Naming service in a distributed memory object architecture

Disclosed herein is an apparatus and method for a distributed memory object system. In one embodiment, a method includes forming a system cluster comprising a plurality of nodes, wherein each node includes a memory, a processor and a network interface to send and receive messages and data, electing a cluster manager to mediates cluster membership, node identification assignment, and a name service group, creating a node manager to initiate services for each of the plurality of nodes, wherein the node manager is configured to notify the cluster manager of its existence and node health, and creating a plurality of sharable memory spaces, wherein each space is a distributed memory object having an object owner node, and partitioning address space within each sharable memory space into chunks, wherein data may be placed in one or more memory regions mapped to the distributed memory object by either of a store call or a write call, and data stored in one or more memory regions mapped to the direct memory object may be accessed by a load call or a read call.

Distributed memory object method and system enabling memory-speed data access in a distributed environment

Disclosed herein is an apparatus and method for a key value store snapshot for a distributed memory object system. In one embodiment, a method includes forming a system cluster comprising a plurality of nodes, wherein each node includes a memory, a processor and a network interface to send and receive messages and data; creating a plurality of sharable memory spaces having partitioned data, wherein each space is a distributed memory object having a compute node, wherein the sharable memory spaces are at least one of persistent memory or DRAM cache; storing data in persistent memory, the data having a generation tag created from a generation counter and a doubly linked list having a current view and a snapshot view, the data further being stored in either a root or a persisted row; creating a snapshot comprising a consistent point-in-time view of key value contents within a node and incrementing the generation counter; copying the snapshot to a second node; regenerating an index for the key value contents within the node; and logging updates since the snap was applied to update copied data in the second node.

Key value store snapshot in a distributed memory object architecture

Disclosed herein is an apparatus and method for a shuffle manager for a distributed memory object system. In one embodiment, a method includes forming a system cluster comprising a plurality of nodes, wherein each node includes a memory, a processor and a network interface to send and receive messages and data, wherein the network interface operates on remote direct memory access; creating a plurality of sharable memory spaces having partitioned data, wherein each space is a distributed memory object having a compute node, wherein the sharable memory spaces are at least one of persistent memory or DRAM cache; and storing data in an in-memory data structure when there is available memory in a compute node; and if there is an out of memory condition, serializing at least some of the in-memory data and spilling it to a distributed memory object system to persist shuffled data outside the compute node.

Shuffle manager in a distributed memory object architecture

Disclosed herein is a persistent memory (PMEM)-based distributed memory object system, referred to as the PMEM DMO system, that provides affordable means of integrating low-latency PMEM spaces with other devices, including servers that do not directly support PMEM. One embodiment comprises providing a cluster of servers with PMEM storage (PMEM servers) and connecting the PMEM servers to a plurality of applications servers using a low-latency network, such as a remote direct memory access; background processes on each of the application servers are tasked to perform input/output operations for the application servers to locally materialize objects from and synchronize/persist objects to the remote PMEM spaces on the PMEM servers. Data materialized from the PMEM servers is stored to the local cache of the application server for use. Also disclosed are data eviction policies for clearing the local cache of the application servers to make space for new data read.

Cost-effective deployments of a PMEM-based DMO system

Disclosed herein is an apparatus and method for a distributed memory object system. In one embodiment, a method includes forming a system cluster comprising a plurality of nodes, wherein each node includes a memory, a processor and a network interface to send and receive messages and data; creating a plurality of sharable memory spaces having partitioned data, wherein each space is a distributed memory object having a compute node, wherein the sharable memory spaces are at least one of persistent memory or DRAM cache; at a client, establishing an inter process communication between the client and a distributed memory object service; receiving a meta chunk including attributes about a file and a chunk map from a distributed memory object service, wherein the meta chunk includes chunk information including identity and location of a data chunk; and the client mapping the data chunk into virtual memory address space and accessing it directly.

Distributed memory object apparatus and method enabling memory-speed data access for memory and storage semantics

Growing community of inventors

Fremont, CA, United States of America

Yue Li