US 20090150511 A1
A computer network with distributed shared memory, including a clustered memory cache aggregated from and comprised of physical memory locations on a plurality of physically distinct computing systems. The network also includes a plurality of local cache managers, each of which are associated with a different portion of the clustered memory cache, and a metadata service operatively coupled with the local cache managers. Also, a plurality of clients are operatively coupled with the metadata service and the local cache managers. In response to a request issuing from any of the clients for a data item present in the clustered memory cache, the metadata service is configured to respond with identification of the local cache manager associated with the portion of the clustered memory cache containing such data item.
1. A computer network with distributed shared memory, comprising:
a clustered memory cache aggregated from and comprised of physical memory locations on a plurality of physically distinct computing systems;
a plurality of local cache managers, each of the local cache managers being local to and associated with a different portion of the clustered memory cache;
a metadata service operatively coupled with the local cache managers; and
a plurality of clients operatively coupled with the metadata service and the local cache managers,
where in response to a request issuing from any of the clients for a data item present in the clustered memory cache, the metadata service is configured to respond with identification of the local cache manager associated with the portion of the clustered memory cache containing such data item.
2. The computer network of
3. The computer network of
4. The computer network of
5. The computer network of
6. The computer network of
7. The computer network of
8. The computer network of
9. The computer network of
10. The computer network of
11. The computer network of
12. The computer network of
13. The computer network of
14. The computer network of
15. The computer network of
16. The computer network of
17. A method of operating a networked memory resource, comprising:
running a local memory manager on each of a plurality of physically distinct computing systems operatively coupled with each other via network infrastructure;
instantiating a metadata service operatively coupled with each the local memory managers via the network infrastructure;
conducting communications between the local memory managers and the metadata service to provide the metadata service with information about physical memory locations disposed on each of the plurality of physically distinct computing systems;
employing the metadata service as a directory service to facilitate aggregation of and addressing of the physical memory locations of each of the plurality of physically distinct computing systems, such that the physical memory locations are collectively usable by clients as an undifferentiated memory resource.
18. The method of
19. The method of
20. The method of
21. The method of
22. The method of
23. The method of
24. The method of
25. The method of
26. A networked computer system with a networked memory resource, comprising:
a plurality of local memory managers, each of which is configured to run on a different one of a plurality of physically distinct computing systems operatively coupled with each other via network infrastructure; and
a metadata service operatively coupled with each the local memory managers via the network infrastructure;
where the metadata service and the local memory managers are configured to communicate with each other to provide the metadata service with information about physical memory locations disposed on each of the plurality of physically distinct computing systems,
and where the metadata service is configured to provide a directory service to facilitate aggregation of and addressing of the physical memory locations of each of the plurality of physically distinct computing systems, such that the physical memory locations are collectively usable by clients as an undifferentiated memory resource.
27. The system of
28. The system of
29. The system of
30. The system of
31. The system of
The present application claims priority to U.S. Provisional Patent Application Ser. No. 60/986,377, entitled RESOURCE CLUSTERING IN ENTERPRISE NETWORKS filed Nov. 8, 2007, the disclosure of which is hereby incorporated by reference.
The present disclosure relates to sharing memory resources in computer networks. A broad class of computing innovation involves the combining of computing resources to provide various benefits. For example, a wide variety of technologies are used to allow distributed storage devices (e.g., hard drives) to be combined and logically accessed as a unified, shared storage resource. Processing resources have also been combined and/or divided, for example, in multiprocessor and parallel processing systems, and in virtual machine environments.
The sharing of computer memory (RAM) has proved more difficult in many respects. Typically, discrete memory chips are combined by tightly coupling the chips together with specialized bus circuits, such as on RAM modules, desktop computer motherboards, and the like. Accordingly, hardware requirements often impose limitations on the ability to share and/or increase memory capacity. Although various solutions have been proposed, the solutions commonly involve significant architectural changes and often require specialized software to take advantage of the changed memory architecture.
Clustered memory cache 22 provides a shared memory resource that can be accessed and used by the clients. Specifically, depending on the mode of operation, clients 32 can read from the clustered memory cache and cause insertion and/or eviction of data items to/from the cache.
As used herein, “client” will at times broadly to refer to any hardware or software entity that makes use of the shared memory resource. For example, clients may include personal computers, workstations, servers and/or applications or other software running on such devices. The invention has proved particular useful in accelerating the performance of server applications that perform operations on large volumes of data, such as complicated modeling and simulation applications in fields such as finance, engineering, etc. In such a setting, the performance of the client application can be enhanced significantly through appropriately managed use of the shared memory resource.
“Client” may also more specifically refer to a driver or other software entity that facilitates access to the shared memory resource. For example, as will be described in more detail, a driver can be loaded into memory of a networked computer, allowing applications and the operating system of that computer to “see” and make use of the clustered cache.
The distributed shared memory described herein may be operated in a variety of modes. Many of the examples discussed herein will refer to a mode where clustered memory cache 22 provides page caching functionality for data used by clients 32. In particular, data items from an auxiliary store 50 may be cached in clustered memory cache 22. Thus, even though a particular client may have ready access to the auxiliary store (e.g., access to a file system stored on a hard disk), it will often be desirable to place requested data in the clustered memory cache, so as to provide faster access to the data. Auxiliary store 50 can include one or more storage devices or systems at various locations, including hard disks, file servers, disk arrays, storage area networks, and the like.
Regardless of the particular mode of operation, the clustered memory cache spans multiple physically distinct computing systems. For example, in
Referring particularly to local memory managers 34, each memory manager is local to and associated with a different portion of clustered memory cache 22. The memory managers typically are independent of one another, and each is configured to allocate and manage individual units of physical memory in its associated portion of clustered memory cache 22.
The local memory managers typically are configured to manage client references and access to cached data items. As an illustration, assume a particular client 32 needs access to a data item cached in the portion of clustered cache 22 that is managed by memory manager MM1. Assuming the client knows the memory location for the cached item is managed by MM1, the client contacts MM1 to gain access to the cached item. If access is permitted, the memory manager MM1 grants access and maintains a record of the fact that the requesting client has a reference to the memory location. The record may indicate, for example, that the client has a read lock on a particular block of memory that is managed by memory manager MM1.
In some embodiments, clustered memory cache 22 may be implemented using Remote Direct Memory Access (RDMA). RDMA implementations that may be employed include the Virtual Interface Architecture, InfiniBand, and iWARP. In such a setting, the local memory manager may be configured to provide RDMA keys to requesting clients or otherwise manage the respective access controls of the RDMA implementation.
For any given memory manager, the associated portion of the clustered cache will often include many different blocks or other units of memory. In particular, referring to
The remaining column or columns contain metadata or other information associated with the corresponding unit of memory and/or the data stored in that unit of memory. As depicted in
Local memory managers 34 may also be configured to receive and respond to requests to insert particular data items into clustered memory cache 22. As will be explained in more detail below, these cache insertion requests can arise from and be initiated by actions of metadata service 30 and clients 32. In some cases, the local memory manager may deny the cache insertion request. One situation where an insertion request can be denied is if the request is directed to a block containing an item that cannot be immediately evicted, for example because there are active client references to the cached item.
Assuming, however, that the insertion request is grantable by the local memory manager, the local memory manager acknowledges and grants the request. The memory manager also coordinates the population of the respective memory block with the data item to be cached, and appropriately updates any associated information for the block in the cache store (e.g., cache store 60).
Similarly, each local memory manager 34 is configured to receive and respond to requests to evict items from its associated portion of clustered memory cache 22. As with insertion requests, the eviction requests can arise from actions of the metadata service 30 and one or more of clients 32, as will be explained in more detail below. Assuming the request is grantable, the memory manager acknowledges and grants the request, and flushes the memory block or takes other appropriate action to make the memory block available for caching of another item.
In some example embodiments, it will be desirable to notify clients 32 when items are to be evicted from the clustered memory cache. Accordingly, the local memory managers may also be configured to maintain back references to clients accessing items in the cache. For example, assume a client requests access to an item in a portion of the cache managed by a memory manager, and that the memory manager has responded by granting a read lock to the client. Having maintained a back reference to the client (e.g., in cache store 60), the local memory manager can then notify the client in the event of a pending eviction and request that the client release the lock.
As discussed above, each local memory manager is local to and associated with a different portion of the clustered memory cache. In the example of
Secondly, the figure demonstrates the use of multiple different clusters. Specifically, each local memory manager and memory segment pairing in the
Local memory managers 34 may also be configured to report out information associated with the respective portions of clustered memory cache 22. As discussed above with reference to
For example, as will be described in more detail below, metadata service 30 can provide a centralized, or relatively centralized, location for maintaining status information about the clustered cache. In particular, in
More particularly, metadata service 30 may include a metadata service data store 80 for maintaining information associated with the memory locations in its domain that form the clustered cache. In one class of examples, and as shown in
Various additional information may be associated with the records of metadata service data store 80. In particular, the metadata service may store a tag for each of the memory locations of the cache, as shown in the figure. In one example, the tag allows a requesting entity, such as one of clients 32, to readily determine whether a particular data item is stored in the cache. Specifically, the tag column entries may each be a hash of the path/filename for the data item resident in the associated memory block. To determine whether a requested data item (e.g., a file) is present in the cache, the path/filename of the requested item is hashed using the same hash routine and the resulting hash is compared to the tag column entries of the metadata service data store 80. The path and filename hash described above is but an example; hash methodologies may be employed on other data, and/or other identification schemes may be employed.
Metadata service data store 80 may also indicate an associated local memory manager for each of its records, as shown at the exemplary column designated “MM.” For example, data store could indicate that a first memory block or range of memory blocks was managed by memory manager MM1, while a second bock or range of blocks was managed by local memory manager MM2. With such a designation, in the event that a query for a particular item reveals the item is present in the cache (e.g., via a match of the path/filename hash described above), then the response to that query can also indicate which local memory manager 34 must be dealt with to read or otherwise access the cached item.
In the example of
The tag, memory manager and status entries described above with reference to the cache blocks in data store 80 are non-limiting examples. As described in more detail below, metadata service 30 and its policy engine 90 typically play a role in implementing various policies relating to the configuration and usage of clustered memory cache 22. Application of various policies can be dependent upon rates of eviction and insertion for a cache block or data item; temporal information such as the time a data item has been cached in a particular block, time since last access, etc.; and/or other information concerning the cache block, such as statistical information regarding usage of the cache block or the data items cached therein.
It will thus be appreciated that the information maintained in metadata service data store 80 may overlap to some extent with the information from the various cache stores 60 (
Also, the metadata service may be distributed to some extent across the network infrastructure. For example, multiple mirrored copies of the metadata service may be employed, with each being assigned to a subset of local memory managers. Memory manager assignments would be dynamically reconfigured to achieve load balancing and in the event of failure or other changes in operating conditions of the environment.
Various examples will now be described illustrating how clients 32 interact with metadata service 30 and local memory managers 34 to access clustered memory cache 22. The basic context of these examples is as follows: a particular client 32 (
In a first example, the financial analysis program makes an attempt to access a data file that has already been written into clustered memory cache 22. This may have occurred, for example, as a result of another user causing the file to be loaded into the cache. In this example, client 32 acts as a driver that provides the analysis program with access to the clustered memory cache 22. Other example embodiments include client 32 operating in user mode, for example as an API for interacting with the clustered resource.
In response to the client request for the data file, metadata service 30 determines that the requested file is in fact present in the cache. This determination can be performed, for example, using the previously-described filename/path hash method. Metadata service 30 then responds to the request by providing client with certain metadata that will enable the client to look to the appropriate portion of the clustered memory cache (i.e., the portion containing the requested file).
In particular, metadata service 30 responds to the request by identifying the particular local memory manager 34 which is associated with the portion of the cache containing the requested file. This identification may include the network address of the local memory manager, or another identifier allowing derivation of the address. Once the client has this information, the client proceeds to negotiate with the local memory manager to access and read the requested file from the relevant block or blocks managed by the memory manager. This negotiation may include granting of a read lock or other reference from the local memory manager to the client, and/or provision of RDMA keys as described above.
As shown in
Another example will now be considered, in which the file requested by the analysis program is not present in clustered memory cache 22. As before, the analysis program and/or client 32 cause the file request to issue, and the request is eventually received at metadata service 30. Prior to messaging of the request to metadata service 30, however, the local client store 92 of metadata is consulted. In this case, because the requested file is not present in the cache, no valid metadata will be present in the local store. The request is thus forward to metadata service 30.
In response to the request, metadata service 30 cannot respond with a memory manager identification, as in the previous example, because the requested file is not present in the clustered memory cache. Accordingly, the hash matching operation, if applied to metadata service data store 80, will not yield a match.
The metadata service can be configured to implement system policies in response to this type of cache miss situation. Specifically, policies may be implemented governing whether the requested item will be inserted into the clustered memory cache, and/or at what location in the cache the item will be written. Assuming clustered cache 22 is populated with the requested item, the metadata service data store 80 will be updated with metadata including the designation of the responsible memory manager 34. This metadata can then be supplied in response to the original request and any subsequent requests for the item, so that the cached version can be accessed through client interactions with the appropriate memory manager.
The systems and methods described herein may be configured with various policies pertaining to the shared memory resource. Policies may control configuration and usage of the clustered memory cache; client access to the cache; insertion and eviction of items to and from the cache; caching of items in particular locations; movement of cached items from one location to another within the cache; etc. Policies may also govern start/stop events, such as how to handle failure or termination of one of the computing systems contributing memory locations to the cluster. These are non-limiting examples—a wide variety of possibilities exist.
In the example of
For example, in
Configuration manager 42 typically also coordinates registration and policy distributions for metadata service 30 and local memory managers 34. The distributed policies are stored locally and implemented via metadata service policy engine 90 (
As indicated above, policy manager 44 typically is configured to provide a master/central store for the system policy definitions, some or all of which may be derived from inputs received via admin interface 46. Policy manager 44 may also validate or verify aggregate policies to ensure that they are valid and to check for and resolve policy conflicts. The policy manager 44 typically also plays a role in gathering statistics relating to policy implementations. For example, the policy manager may track the number of policy hits (the number of times particular policies are triggered), and/or the frequency of hits, in order to monitor the policy regime, provide feedback to the admin interface, and make appropriate adjustments. For example, removal of unused policies may reduce the processing overhead used to run the policy regime.
As should be appreciated from the foregoing, although the policies may be defined and managed centrally, they typically are distributed and implemented at various locations in the system. Furthermore, the policy ruleset in force at any given location in the system will typically vary based on the nature of that location. For example, relative to any one of memory managers 34 or clients 32, metadata service 30 has a more system-wide global view of clustered memory cache 22. Accordingly, policy rulesets affecting multiple clients or memory managers typically are distributed to and implemented at metadata service 30.
Referring to clients 32, and more particularly to the client policy engines 94 incorporated into each client, various exemplary client-level policy implementations will be described. Many example policies implemented at the clients operate as filters to selectively control which client behaviors are permitted to impact the shared memory resource. More specifically, the client policy engine may be configured to control whether requests for data items (e.g., an application attempting to read a particular file from auxiliary store 50) are passed on to metadata service 30, thereby potentially triggering an attempted cache insertion or other action affecting the clustered cache.
The selective blocking of client interactions with metadata service 30 operates effectively as a determination of whether a file or other data item is cacheable. This determination and the corresponding policy may be based on a wide variety of factors and criteria. Non-limiting examples include:
Cache insertion policies determine whether or not a file or other data item may be inserted into clustered memory cache 22. Typically, cache insertion policies are applied by metadata service 30 and its policy engine 90, though application of a given policy will often be based upon requests received from one or more clients 32, and/or upon metadata updates and other messaging received from the local memory managers 34 and maintained in metadata service data store 80 (
In some examples, administrators or other users are able to set priorities for particular items, such as assigning relatively higher or lower priorities to particular files/paths. In addition, the insertion logic may also run as a service in conjunction with metadata service 30 to determine priorities at run time based on access patterns (e.g., file access patterns compiled from observation of client file requests).
Further non-limiting examples of cache insertion policies include:
Metadata service 30 also implements eviction policies for the clustered memory cache 22. Eviction policies determine which data items to evict from the cache as the cache reaches capacity. Eviction policies may be user-configured (e.g., by an administrator using admin interface 46) based on the requirements of a given setting, and are often applied based on metadata and other information stored at metadata service 30 and/or memory managers 34.
In particular, metadata service 30 may reference its data store 80 and predicate evictions based on which memory location within its domain has been least recently used (LRU) or least frequently used (LFU). Other possibilities include evicting the oldest record, or basing evictions on age and frequency based thresholds. These are but examples, and evictions may be based upon a wide variety of criteria in addition to or instead of these methods.
As previously mentioned, although metadata service 30 has a global view of the cache and is therefore well-positioned to make insertion/eviction determinations, the actual evictions and insertions typically are carried out by the memory managers 34. Indeed, the insertion/eviction determinations made by metadata service 30 are often presented to the memory managers as requests that the memory managers can grant or deny. In other cases, the memory manager may grant the request, but only after performing other operations, such as forcing a client to release a block reference prior to eviction of the block.
In other cases, metadata service 30 may assign higher priority to insertion/eviction requests, essentially requiring that the requests be granted. For example, the overall policy configuration of the system may assign super-priority to certain files. Accordingly, when one of clients 32 requests a super-priority file, if necessary the metadata service 30 will command one or more memory managers 34 to evict other data items and perform the insertion.
The general case, however, is that the local memory managers have authority over the cache memory locations that they manage, and are able in certain circumstances to decline requests from metadata service 30. One reason for this is that the memory managers often have more accurate and/or current information about their associated portion of the cache. Information at the memory managers may be more granular, or the memory managers may maintain certain information that is not stored at or reported to metadata service 30. On the other hand, there may be delays between changes occurring in the cache and the reporting of those changes from the respective memory manager to metadata service 30. For example, metadata service 30 might show that a particular block is evictable, when in fact its memory manager had granted multiple read locks since the last update to the metadata service. Such information delays could result from conscious decisions regarding operation of the clustered cache system. For example, an administrator might want to limit the reporting schedule so as to control the amount of network traffic associated with managing the shared memory resource.
The above-described distribution of information, functionality and complexity can provide a number of advantages. The highly-distributed and non-blocking nature of many of the examples discussed herein allows them to be readily scaled in large datacenter environments. The distributed locking and insertion/eviction authority carried out by the memory managers allows for many concurrent operations and reduces the chance of any one thread blocking the shared resource. Also, the complicated tasks of actually accessing the cache blocks are distributed across the cluster. This distribution is balanced, however, by the relatively centralized metadata service 30, and the global information and management functionality it provides.
Furthermore, it should be appreciated that various different persistence modes may be employed in connection with the clustered memory resource described herein. In many of the examples discussed herein, a read-only caching mode is described, where the clustered resource functions to store redundant copies of data items from an underlying auxiliary store. Performance is dramatically enhanced, because the cluster provides a shareable resource that is much faster than the auxiliary store where the data originates. However, from a persistence standpoint, the data in the cluster may be flushed at any time without concern for data loss because the cluster does not serve as the primary data store. Alternatively, the cluster may be operated as a primary store, with clients being permitted to write to locations in the cluster in addition to performing read operations. In this persistence mode, the cluster data may be periodically written to a hard disk or other back-end storage device.
A further example of how the clustered memory resource may be used is as a secondary paging mechanism. Page swapping techniques employing hard disks are well known. The systems and methods described herein may be used to provide an alternate paging mechanism, where pages are swapped out the high performance memory cluster.
The exemplary policy regimes described herein may also operate to control the location in clustered memory cache 22 where various caching operations are performed. In one class of examples, metadata service 30 selects a particular memory manager 34 or memory managers to handle insertion of a file or other item into the respective portion of the cache. This selection may be based on various criteria, and may also include spreading or striping an item across multiple portions of the cluster to provide increased security or protection against failures.
In another class of examples, the metadata service coordinates migration of cached items within clustered memory cache 22, for example from one location to another in the cache. This migration may be necessary or desirable to achieve load balancing or other performance benefits.
A variety of exemplary locality policies will now be described, at times with reference to
In a first example, cache insertion locality is determined based on relative usage of memory locations 24. Usage information may be gathered over time and maintained by memory managers 34 and the metadata services, and maintained in their respective stores. Usage may be based on or derived from eviction rates, insertion rates, access frequency, numbers of locks/references granted for particular blocks, etc. Accordingly, when determining where to insert an item in clustered memory cache 22, the metadata service may select a less utilized or underutilized portion of the cache to achieve load balancing.
The metadata service may also coordinate migration of cache items from one location to another based on relative usage information. For example, if information in metadata service data store 80 (
In another example, locality policies are implemented based on location of the requesting client. Assume for example, with reference to
In another example, the relative location of the underlying data item is factored into the locality policy. Referring to
From the above, it should be understood that locality may be determined by tracking usage patterns across the cluster and migrating memory blocks to nodes optimized to reduce the total number of network hops involved in current and anticipated uses of the cluster. In many cases, such optimization will significantly reduce latency and potential for network congestion. The usage data may be aggregated from the clients by the configuration manager and propagated to the metadata service(s) as a form of policy that prioritizes various cache blocks.
The policy implementation may also be employed to detect thrashing of data items. For example, upon detecting high rates of insertion and eviction for a particular data item, the system may adjust to relax eviction criteria or otherwise reduce the thrashing condition.
A further locality example includes embodiments in which a block or data item is replicated at numerous locations within the clustered memory resource. For example, in a caching system, multiple copies a given cache block could be sited at multiple different locations within the clustered cache. A metadata service query would then result in identification of one of the valid locations. In certain settings, such replication will improve fault tolerance, performance, and provide other advantages.
Referring now to
The method may generally include running a local memory manager on each of a plurality of physically distinct computing systems operatively coupled with each other via network infrastructure. One or more metadata services are instantiated, and operatively coupled with the network infrastructure. Communications are conducted between the metadata service(s) and the local memory managers to provide the metadata service with metadata (e.g., file/path hashes, usage information/statistics, status, etc.) associated with the physical memory locations. The metadata service is then operated to provide a directory service and otherwise coordinate the memory managers, such that the physical memory locations are collectively usable by clients as an undifferentiated memory resource.
Referring specifically to the figure, at 122, method 120 may also include issuing of a client request. As in the examples described above, the request may originate or issue from an operating system component, application, driver, library or other client entity, and may be directed toward a file or other data item residing on a file server, disk array or other auxiliary store.
As shown at 124, method 120 may also include checking a local store to determine whether metadata is already available for the requested item. The existence of local metadata indicates that the requested item is currently present and active in the clustered memory cache, or at least that it was at some time in the past. If local metadata is available, a read lock is obtained if necessary (126) and the item is read from its location in clustered memory cache (128).
In the context of
If the requested item is not eligible for caching, the request is satisfied by means other than through the clustered memory cache. In particular, as shown at 132, the client request is satisfied through auxiliary access, for example by directly accessing a back-end file system residing on auxiliary store 50 (
Proceeding to 134, a metadata service may be accessed for eligible requests that cannot be initiated with locally stored metadata. Similar to the inquiry at step 124, the metadata service is queried at 136 to determine whether metadata exists corresponding to the client request. If the metadata service has current metadata for the request (e.g., the address of a local memory manager overseeing a portion of cache 22 where the requested item is cached), then the metadata is returned to the requesting entity (138), and the access and read operations may proceed as described above with reference to steps 126 and 128.
The absence of current metadata at the queried metadata service is an indication that the requested item is not present in the shared memory resource (e.g., clustered memory cache 22 of
As in the various examples discussed with reference to
As also shown at 142, the cache insertion may also include messaging or otherwise conferring with one or more local memory managers (e.g., memory managers MM1, MM2, etc. of
As previously discussed, the memory manager in some cases may deny the insertion request, or may honor the request only after performing an eviction or other operation on its managed memory location(s). Indeed, in some cases, insertion requests will be sent to different memory managers, successively or in parallel, before the appropriate insertion location is determined. In any event, the insertion process will typically also include updating the metadata service data store, as also shown at 144. For example, in the case of a cached file, the data store 80 of metadata service 30 (
As shown at 146, if the insertion is successful, metadata may be provided to the client and the access and read operations can then proceed (138, 126, 128). On the other hand, failed insertion attempts may result in further attempts (142, 144) and/or in auxiliary access of the requested item (132).
Referring now to
In the example of
Alternatively, cluster interface 602 is configured to bypass file system layer 604 in some cases and read the requested data from a location in the shared memory resource (e.g., a memory location 24 in clustered memory cache 22), instead of from the auxiliary store 50. As indicated, this access of the clustered resource may occur via a client RDMA layer 610 and a target host channel adapter 612.
Cluster interface 602 may perform various functions in connection with the access of the shared memory resource. For example, interface 602 may search for and retrieve metadata in response to a request for a particular file by application 600 (e.g., as in step 124 or steps 134, 136 and 138 of
In one example embodiment, cluster interface 602 interacts with the virtual memory system of the client device, and employs a page-fault mechanism. Specifically, when a requested item is not present in the local memory of the client device, a virtual memory page fault is generated. Responsive to the issuance of the page fault, cluster interface 602 performs the previously described processing to obtain the requested item from the auxiliary store 50 or the shared memory cluster. Cluster interface 602 may be configured so that, when use of the clustered cache 22 is permitted, item retrieval is attempted by the client simultaneously from auxiliary store 50 and clustered memory cache 22. Alternatively, attempts to access the clustered cache 22 may occur first, with auxiliary access occurring only after a failure.
Depending on the particular configuration employed at the client, block-level or file-level invalidation may be employed. For example, in the event that an application is writing to a data item that is cached in the clustered resource, the cached copy is invalidated, and an eviction may be carried out at the local memory/cache manager in the cluster where the item was stored. Along with the eviction, messaging may be sent to clients holding references to the cached item notifying them of the eviction. Depending on the system configuration, the clients may then perform block or file-level invalidation.
Furthermore, it will be appreciated that variable block sizes may be employed in block-based implementations. Specifically, block sizes may be determined in accordance with policy specifications. It is contemplated that block size may have a significant affect on performance in certain settings.
Finally, configurations may be employed using APIs or other mechanisms that are not file or block-based.
It will be appreciated that the computing devices described herein may be any suitable computing device configured to execute the programs described herein. For example, the computing devices may be a mainframe computer, personal computer, laptop computer, portable data assistant (PDA), computer-enabled wireless telephone, networked computing device, or other suitable computing device, and may be connected to each other via computer networks, such as the Internet. These computing devices typically include a processor and associated volatile and non-volatile memory, and are configured to execute programs stored in non-volatile memory using portions of volatile memory and the processor. As used herein, the term “program” refers to software or firmware components that may be executed by, or utilized by, one or more computing devices described herein, and is meant to encompass individual or groups of executable files, data files, libraries, drivers, scripts, database records, etc. It will be appreciated that computer-readable media may be provided having program instructions stored thereon, which upon execution by a computing device, cause the computing device to execute the methods described above and cause operation of the systems described above.
It should be understood that the embodiments herein are illustrative and not restrictive, since the scope of the invention is defined by the appended claims rather than by the description preceding them, and all changes that fall within metes and bounds of the claims, or equivalence of such metes and bounds thereof are therefore intended to be embraced by the claims.