Browse Prior Art Database

Shared cache and multi-node cluster environment.

IP.com Disclosure Number: IPCOM000247127D
Publication Date: 2016-Aug-08
Document File: 5 page(s) / 72K

Publishing Venue

The IP.com Prior Art Database

Related People

Sanjay Jain: INVENTOR [+6]

Abstract

The proposal is to use a shared device to cache frequently accessed data in order to improve application performance. Since the data is shared, there is no need to invalidate the data when any node is trying to modify it. Also, irrespective of which node populates the data, once data is there in the cache, it is visible to all the nodes sharing the cache. This also reduces burden on underlying infrastructure (network, storage etc.), making them respond faster for other IOs.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 25% of the total text.

Page 01 of 5

Shared cache and multi-node cluster environment.

  Sanjay Jain Ajay Salpekar Charles Silvers Brad Boyer Anindya Banerjee

Sushil Patil

Abstract

The proposal is to use a shared device to cache frequently accessed data in order to improve application performance. Since the data is shared, there is no need to invalidate the data when any node is trying to modify it. Also, irrespective of which node populates the data, once data is there in the cache, it is visible to all the nodes sharing the cache. This also reduces burden on underlying infrastructure (network, storage etc.), making them respond faster for other IOs.

Problem Statement

A cache device improves performance of an application by caching data belonging to working set of an application. As data is cached in caching device, application does not need to go to main storage, which may be SAN storage or a slower device, to fetch data. In a multi-node cluster, if each node has a separate cache device, then cache population need to happen on each node separately. Also if any node modifies the cached data then the modified range need to be invalidated from other node's cache to maintain cache coherency. Once cached data is invalidated then it may need to be populated again. This may have impact on application performance if working set of application data needs frequent invalidation and re- population, because a large percentage of working set is common among cluster nodes.

Publication Description

The idea is to make use of a shared cache across nodes in cluster. All data which is in the cache are accessible by all nodes.

In a clustered environment, a global range lock, which supports locking of ranges, is used to control concurrent access to different regions of file data. If any range of file is accessed from a node in cluster say N1, then global range lock for this range is taken on node N1. This lock may be taken in SH or EX mode depending upon type of operation. For read

1

© 2016 Veritas Technologies LLC. All rights reserved. Veritas and the Veritas Logo are trademarks or registered trademarks of Veritas Technologies LLC or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners.


Page 02 of 5

operation, this lock may be taken in SH mode and for write the range lock may be taken in EX mode.

Let's see following operations for a file range done from Node N1 and Node N2 -

Read(N1)-Read(N2)

For read operation, global range lock may be taken in SH mode on N1 for the range. The data is first searched in shared cache. If data is found then this data is given to application. If data is not found then data is obtained from main storage and given to application. This data may also be populated in the shared cache in same context or asynchronously by some worker thread. If another node say N2 now read from this file range with SH range lock, then data which is there in shared cache can be given to application as it got populated while N1 ac...