Near-cache distribution of manifest among peer applications in in-memory data grid (IMDG) non structured query language (NO-SQL) environments

Near cache distribution in in-memory data grid environment that utilizes manifest of keys may be provided. An application instance may be initialized that utilizes an in-memory data grid caching infrastructure with a near cache in a virtual machine running on hardware processor. The near cache for the application instance may be activated. Logic of the near cache associated with the application instance may request a manifest of keys from one or more peer applications utilizing the in-memory data grid caching infrastructure, and receive the manifest of keys. The logic of the near cache associated with the application instance may send the manifest of keys to a grid cache of the in-memory data grid caching infrastructure. The logic of the near cache associated with the application instance may receive at least some of the data objects from the grid cache.

FIELD

The present application relates generally to computers, and computer applications, and more particularly to near cache distribution in in-memory data grid (NO-SQL) environments.

BACKGROUND

To speed up application performance, techniques have been employed that cache data at various tiers in application infrastructure, for example, including edge, ultra edge, data grid and near cache. Other techniques like cache optimization on server side that use predictive cache load from back end databases based on pattern of data access have also been employed. Replication, snapshots and vMotion like VM movement are some other techniques used to improve the speed of virtual machine (VM) instance provisioning.

BRIEF SUMMARY

A method and system of near cache distribution, for example, in in-memory data grid (IMDG) environment may be provided. The method, in one aspect, may comprise initiating an application instance that utilizes an in-memory data grid caching infrastructure with a near cache in a virtual machine running on hardware processor. The method may further comprise activating the near cache for the application instance on the virtual machine. The method may also comprise requesting, by logic of the near cache associated with the application instance from one or more peer application servers utilizing the in-memory data grid caching infrastructure, a manifest of keys, the keys associated with data objects. The method may also comprise receiving, by the logic of the near cache associated with the application instance the manifest of keys. The method may further comprise sending, by the logic of the near cache associated with the application instance, the manifest of keys to a grid cache of the in-memory data grid caching infrastructure. The method may further comprise receiving, by the logic of the near cache associated with the application instance, at least some of the data objects from the grid cache.

A system for near cache distribution, for example, in in-memory data grid (IMDG) environment, in one aspect, may comprise an application server operable to run as a member of a cluster of application servers utilizing an in-memory data grid caching infrastructure, at least some of the application servers for running application instances of the same application. A near cache may be provided comprising logic and allocated memory in the application server. A manifest file associated with the application server may be provided. Responsive to initiating an application instance hosted on the application server, the near cache may be activated for the application instance. The application server may be operable to request a manifest of keys from one or more peer application servers in the cluster utilizing the in-memory data grid caching infrastructure, the keys associated with data objects. The application server may be further operable to receive the manifest of keys and send the manifest of keys to a grid cache of the in-memory data grid caching infrastructure. The application server may be further operable to receive at least some of the data objects from the grid cache.

DETAILED DESCRIPTION

A grid generally includes loosely coupled computers that function together to run tasks. In-Memory Data Grid (IMDG) refers to a data store that uses main memory, for example, random access memory (RAM) as a storage area. IMDG data may be distributed and stored across multiple servers, e.g., in a grid manner using caches of those servers to store data. The data model of IMDG is usually object-oriented or object-based, and data in IMDG may be accessed using a key/value pair pattern.

In multi-tenant or multi-tenancy environment, a single instance of application or software runs on a server and services multiple groups of users (tenants). For instance, multiple users who do not see or share each other's data can share the same application (the same instance of software) running on the same operating system, using the same hardware and the same data storage mechanism.

A methodology and/or system are disclosed that improves application performance in applications utilizing in-memory data grid, for example, in application environments such as multi-tenancy environment. The methodology allows for an application running on an application server to be aware of the types of requests its peers are serving, and to proactively request such types of requests from a source peer and/or from an in-memory data grid. For instance, when an application is started in a clustered virtual machine set up such as the Java™ Virtual Machine (JVM) setup, it may be beneficial to the application to know, from other instances of the same application in the cluster that were started before it, what objects it will need to operate. A cluster is a collection of servers, which may include hardware, software (e.g., application servers) and/or virtual machines such as JVMs that communicate with each other to perform group services, for example, providing high availability and failover mechanisms. Clustered JVM setup refers to a collection of JVMs, for example, running one or more applications. The methodology of the present disclosure in one embodiment may be utilized as an intelligent optimization on an IMDG client side to disseminate metadata on requested object to the peer servers and also to make a single request to data grid that can send the needed object to the peer cluster members. An application server or JVM that requests data in IMDG infrastructure are considered to be an IMDG client; an IMDG server of the IMDG infrastructure services or provides the requested data from grid caches of IMDG to IMDG clients.

In one embodiment of the present disclosure, a manifest is developed and utilized that allow applications running, for example, on application servers (e.g., virtual machines or JVMs) to be aware and to participate in polling for expressing interest and proactive need of data in near cache or local cache. Briefly, near cache schema includes cache local to the application serving as a cache for server-side cache.

In one aspect, the methodology of the present disclosure may increase and induce application awareness between peer application servers, for example, enable an efficient mechanism of surgical distribution of like data in near cache for improved application performance, and also provide a mechanism or apparatus to on-board new applications (e.g., JVMs), e.g., in a multi-tenant cloud environment.

Briefly, cloud computing is a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service. The cloud model may include different characteristics, different service models and different deployment models. Examples of the service models include Software as a Service (SaaS) and Platform as a Service (PaaS) service models. In Software as a Service (SaaS) service model, the consumer may be provided the capability to use the provider's applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings. In Platform as a Service (PaaS), the consumer may be provided the capability to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including networks, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations. Those are some examples of cloud service models to which a methodology of the present disclosure in one embodiment may apply.

A cloud computing environment is usually service oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure comprising a network of interconnected nodes. It is understood in advance that although this disclosure includes a detailed description on cloud computing, implementation of the teachings recited herein are not limited to a cloud computing environment. Rather, embodiments disclosed herein are capable of being implemented in conjunction with any other type of computing environment now known or later developed, as applicable.

FIG. 1is a diagram illustrating near cache distribution in IMDG environment in one embodiment of the present disclosure. When an application is started in a clustered JVM setup, it can benefit from knowing from other instances of the same application in the cluster that were started before it, what objects the application will need to operate. The application may broadcast its need for an object to their peer applications in a cluster. For instance, applications that are running are primed with cached data. A new application server may start and join the cluster of application servers running the applications, for example, to help in load balancing. The new application server, however, may not be primed with the data objects it may need to run. Based on an application that may start or run on the new application server that joined the cluster, a cache manifest of the present disclosure in one embodiment may assist in asserting interest in cached data objects, and receiving the cached data objects from one or more data grid servers that host the cached data objects. In one embodiment, one request may be made and the in-memory data grid may disseminate the needed object to the cluster members (e.g., the applications on the cluster members) that will need the same object. For example, applications102,104,106,108are running in virtual machines112,114,116,118, as part of a virtual machine cluster. In one embodiment of the present disclosure, a manifest (120,122,124,126) may be provided for each of the application servers (112,114,116,118). A manifest is also referred to as a manifest file, and maps an application, a given set of objects that the application needs, and application servers or JVMs interested in the set of objects or requesting the set of objects.

Since an application might not know if it will need an object, the manifest files may be synchronized among the cluster members (112,114,116,118). For instance, when a new cluster member (e.g., a new application server)112joins a cluster of application servers114,116,118, the new cluster member112may initiate a polling process as part of group services, requesting a copy of a current manifest file (e.g., one or more of122,124,126) from one or more peer servers114,116,118in the cluster. Based on the application or applications102hosted by the new cluster member, the new cluster member may identify the data objects it is interested in from the data objects listed in the current manifest file received from one or more peer servers114,116,118. For example, the manifest file122may indicate that the application server114is hosting one or more of the same or similar application as the application server at112, and therefore, the application server112may need some or all of the objects listed in the manifest file of the application server at114. The new cluster member112updates its manifest file120to include the identified data objects that it is interested in. The new cluster member112may send its manifest file120to one or more IMDG servers (e.g., comprising110and128). For example, a manifest file122associated with application server114may include a number of data objects its application104has used while operating or running. Another application server102may start up, but its manifest file120may be empty. The content of the manifest file at122may be copied to the manifest file at120, for example, if it is determined that the applications102and104are running the same software and, for example, it may be assumed that the application at102will use the same data objects as the application at104. Other methods may be used to synchronize the manifest file of a newly started application server with those of the peer application servers. For instance, selective contents of one or more manifest files (e.g.,122,124,126) of respective one or more peer application servers (e.g.,114,116,118) may be copied to the manifest file (e.g.,120) of the new cluster member, for example, based on what applications in common are hosted by the servers in the cluster. It is noted that application servers may host other applications as well.

InFIG. 1, an application server tier (e.g.,102,104,106,108), e.g., in a multi-tenant environment, may include many virtual machines (VM, e.g., JVMs) in a data center environment with many application. The virtual machines (e.g., JVMs shown e.g., at112,114,116,118) may serve as application servers. The virtual machines or application servers may be started on a computer and the applications may be started to run on the virtual machines. This may provide cloud infrastructure or data centers the flexibility to have everything everywhere and enable on-demand start up of applications, for example, based on demand and failures. Each application running on virtual machines or application servers (e.g., JVMs) occupy some VM real estate in form of memory consumption. This memory consumption can be due to normal application class that are loaded on start up or caching requirements to enhance performance.

Applications may also talk to an intermediary tier like a NoSQL databases such as In Memory Data Grid110to improve time on backend data access. IMDG keeps the objects which save time on in memory access and raw data into object conversion. In Memory Data Grid110comprises data used by the applications (e.g.,102,104,106,108). A Grid JVM may hold application data for the grid. For instance, each Grid JVM may store a portion of data used by the application (e.g.,102,104,106,108). Grid JVMs include a set of interconnected java processes that holds the data in memory, for example, acting as shock absorbers to the back end databases128. This not only enabled faster data access, as the data is accessed from memory, but also reduces the stress on database128. Grid JVMs may be allocated in different JVM or hardware from the application servers (e.g.,112,114,116,118). Grid JVMs110hosting data objects may be located on one or more physical machines or hardware. For instance, there may be one or several JVMs on a single physical machine and there may be many physical machines or hardware that form a grid110. Similarly, application servers112,114,116,118may be JVMs on one physical machine or distributed across many physical machines.

Application Servers (e.g.,112,114,116,118) use a communication system for singleton services, for example, for health and heartbeat singleton services. For instance, in a singleton service, multiple clients are independently connected to the same single instance of a server application.

In the present disclosure in one embodiment, the same communication network established by the application server peers may be utilized to synchronize a manifest or manifest file, e.g., also referred to as “near cache object manifest file” (e.g.,120,122,124,126). A manifest file may be stored in near cache of an application server. This near cache object manifest file may be utilized among the cluster peers102,104,106,108and function as a map that allows for application servers or JVMs112,114,116,118to participate in polling for expressing interest and proactive need of data in their respective near cache. For example, one or more application servers in the cluster that are hosting the same application are identified and the data objects cached in those application servers are identified.

A manifest file may contain the identification of data objects, identification of the applications that might need those data objects, and identification of application servers that are interested in getting those data objects. Manifest files (e.g.,120,122,124,126) associated with respective application servers may be synchronized as part of group services functionality. A manifest file may be updated based on membership changes, for example, a new JVM being added, existing JVM being deleted, a new application being instantiated on a JVM. An example manifest file may contain the following:

Client Interested in the Data Object:

After the polling, a list of application servers, which have expressed an interest is tagged with the initial object request, e.g., specified in the manifest file, and the manifest file is sent to the IMDB server, e.g., grid JVM110. IMDB server side may also include backend data128. Backend data128comprises persistent data in raw format, for example, stored in persistent data storage such as storage disks, and backs the grid JVMs stored in memory.

Upon receipt of the request and list of peer servers, the in memory data base servers110may send the same object to application server JVMs in the list tagged with the request. This methodology in one embodiment may reduce communications by every application server, for instance, because only one request informs the data grid110of interested JVMs (e.g., one or more of112,114,116,118).

The following describes an example of initial peer startup or warmup process in one embodiment of the present disclose. A peer or peer application server in the present disclosure refers to a cluster member which has same application and participates in the application serving process. A peer can include both a server and a client: the server which is the IMDG server and the client which is the application server requesting the cached objects for near cache. A peer application refers to an application running on a peer application server.

A new clustered, peer application instance (e.g.,102), which utilizes an IMDG caching infrastructure with a local or near cache may be started. When the local/near IMDG cache is activated for the new application instance, it may request a manifest of keys from one or more other peer local/near cache IMDG instances. Local or near IMDG cache is part of in memory application cache or application server JVM (e.g.,112) that is requesting cached data from IMDG server(s). The new local/near IMDG cache may proactively send the manifest of keys to the IMDG server for fulfillment. The data is sent to the application instance's near/local IMDG cache, for example, using getAll(keys) or another sync mechanism. The peer application is activated and “warmed-up” with cached data.

The following describes and example scenario for runtime maintenance of peer caches and key manifest. A near/local cache of an application server (e.g.,112) receives a request for key A, for example, from an application (e.g.,102) that it is hosting. The requested data does not exist in the near cache of the application (e.g.,102), e.g., in the application server (e.g.,112). The near/local cache (e.g.,112) broadcasts an asynchronous request to all peer near cache instances (e.g.,114,116,118) that A was requested and it does not have it. The near/local cache may update the key manifest (e.g.,120) to add a new cache object request if it is not already there. The near/local cache receives object for A, for example, from the IMDG server. A peer near/local cache receives the broadcast for object A and checks to determine if it has A. If it does not, it fetches it from the grid, for example, by sending a synchronized manifest file to the IMDG server. The IMDG server sends the requested object to the application servers listed in the manifest file (tagged application servers). After fetching, the peer application server keeps the object in near cache for future requests and updates the manifest file, for example, adds object A to its manifest file.

In the present disclosure, applications running on virtual machines or servers in in-memory data base cache tier, e.g., JVMs in IMDG context, communicate with themselves and provide a manifest of interested parties (servers) data that may be needed by the peer servers, e.g., to be proactively loaded in near cache by the IMDG cache tier or cache servers that hold the master data. Near cache is located in application server that hosts the application and far cache (or master data) is located in grid JVMs or a set of IMDG servers.

The methodology of the present disclosure in one embodiment may optimize performance by reducing the number of connections between Application JVMs (application running on an application server, e.g., JVM) and IMDG cache service (IMDG server) and speeding up the understanding of application server cache requirements.

FIG. 2is a flow diagram illustrating a method of near cache distribution in one embodiment of the present disclosure. At202, an application instance is initiated that utilizes an in-memory data grid caching infrastructure with a near cache. It may be that a new application instance is started on an existing JVM or a new JVM started and the application instance started with the new JVM. At204, a near cache is activated for the application instance. For instance, a decision to cache the objects in the JVM running the application instance is made. For example, cache is allocated in the JVM hosting the application instance for the application instance.

At206, a logic of the near cache associated with the application instance requests a manifest of keys from one or more other peer near cache instances. For example, each application server in the peer group may include a near cache logic and allocated cache memory. Each application server in the peer group also may include a manifest of keys associated with data objects the application instance may need to operate or will be using, e.g., because the peer applications may be instances of the same application. The logic of the initiated application instance's near cache, for example, receives from one or more peer application server's near cache logic, the data object keys. The logic of the initiated application instance's near cache, for example, updates the manifest of keys to include or add this application server or virtual machine to a list of one or more peer application servers listed in the manifest of keys to indicate this virtual machine's interest in one or more data objects specified in the manifest of keys. For instance, the virtual machine is tagged in the manifest of keys. Each application server's manifest of keys may be synchronized. Synchronization may be part of group services provided for the peer group, and may be performed periodically or at the time one of the application servers makes an update to its respective manifest of keys. In this way, application servers may express interest in cached object (e.g., those that are most widely used and pertinent to the application hosted) being populated by IMDG or far cache or NO SQL data store (which is also a cache frontend having a persistent data store like DB2). This mechanism not only makes cache population surgical, intelligent but also dynamic.

At208, the application instance's near cache logic sends manifest of keys it received from peer applications to grid cache of the IMDG for fulfillment.

The grid cache may send the requested data objects to the application instance's near cache, and at210, the requested data objects may be received at the application instance's near cache. In one aspect, all of the data objects specified by data object keys in the manifest file tagged as being of interest to this application instance (or application server running this application instance) are received at the near cache from the grid cache. In another aspect, some of the data objects that the application instance will be using may be found in near cache of one or more of the peer applications. In that case, the data objects may be received from the peer application directly, and the data objects not in the near caches of the peer applications may be received from the grid cache.

At212, the application instance is activated and ‘warmed-up’ with cached data, which for example, the application may need when operating.

FIG. 3is a flow diagram illustrating a process of maintaining peer caches and key manifests in one embodiment of the present disclosure. At302, near or local cache receives a request for a data object specified by a key. If this near cache does not have this data object, the logic of the near cache may broadcast an asynchronous request to all peer cache instances that this data object specified by the key was requested and that it does not have it. At304, the near cache updates its key manifest, e.g., manifest file, to include this key. At306, the near cache receives the data object specified by the key. For instance, the data object may be received from a peer near cache that has the data object. If no peer near caches have the data object, one of the peer near caches may fetch the data object from the grid cache. The manifest files associated with the respective peer near caches may be updated.