US20050149562A1

Movatterモバイル変換

Info

Publication number: US20050149562A1
Application number: US10/749,879
Authority: US
Inventors: Michael Browne; Glenn Wightwick
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2003-12-31
Filing date: 2003-12-31
Publication date: 2005-07-07
Also published as: US20070299809A1; CN1292352C; US7818309B2; CN1637722A

Abstract

A method and system are provided for managing requests to access data in a computer environment. In one aspect of the present invention, a request manager receives a request associated with meta data corresponding to data that is maintained separately from the meta data. In another aspect, the request manager informs a data object manager of an anticipated request that will be received by the data object manager to enable it to prepare for the anticipated request. The data object manager commences preparing for the anticipated request in response to being informed of the anticipated request to facilitate a reduction in data access time. In one example of a computing environment utilizing one or aspects of the invention, a storage subsystem comprising a data object manager prepares for the anticipated request by pre-fetching data blocks from storage media into a cache.

Description

TECHNICAL FIELD

This invention relates, in general, to the management of requests to access data in communications environments, and more particularly, to informing a data object manager of an anticipated request to access the data from storage media based on a received request associated with meta data which corresponds to the data.

BACKGROUND OF THE INVENTION

Storage subsystems generally consist of a number of disk drives that can be aggregated and made to appear as virtual disk drives to one or more client computers. To improve performance, storage subsystems usually deploy a cache which is used to hold frequently accessed disk blocks. The choice of which disk blocks to cache can have a significant impact on overall system performance. Some storage subsystems attempt to anticipate which disk blocks may be required by client computers by examining historical patterns of access to disk blocks. The nature of such cache management algorithms is predictive.

Although there are techniques today for the management of requests to access data in communications environments, these techniques can cause a storage subsystem to load data into its cache that is not accessed within the expected time because of their predictive nature. Thus, there is still a need for further techniques to facilitate the management of requests to access data in computer environments.

SUMMARY OF THE INVENTION

The shortcomings of the prior art are overcome and additional advantages are provided through the provision of a method of managing requests. In one aspect, a manager receives a request associated with meta data corresponding to data maintained separately from the meta data. In another aspect of the present invention, the manager informs another manager of an anticipated request that will be received by the another manager to enable it to prepare for the anticipated request.

Systems and computer program products corresponding to the above-summarized methods are also described and claimed herein.

Additional features and advantages are realized through the techniques of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered a part of the claimed invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other objects, features, and advantages of the invention are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:

FIG. 1 illustrates a flowchart of one embodiment of a technique for managing requests associated with data in a computer environment, in accordance with an aspect of the present invention;

FIG. 2 illustrates a flowchart of another embodiment of a technique for managing requests associated with data in a computer environment, in accordance with an aspect of the present invention;

FIG. 3 illustrates one embodiment of a technique for managing requests for access to data in an environment in which data and meta data associated with the data are stored separately, in accordance with an aspect of the present invention;

FIG. 4 illustrates an example of an environment in which a technique for managing requests for access to data is utilized, in accordance with an aspect of the present invention;

FIG. 5 illustrates another example of an environment in which a technique for managing requests for access to data is utilized, in accordance with an aspect of the present invention; and

FIG. 6 illustrates a third example of an environment in which a technique for managing requests for access to data is utilized, in accordance with an aspect of the present invention.

BEST MODE FOR CARRYING OUT THE INVENTION

In one aspect of the present invention, a manager receives a request associated with meta data. The manager informs another manager of an anticipated request to be received the another manager to enable the another manager to prepare for the anticipated request.

A technique for managing requests associated with data in a computer environment in accordance with an aspect of the present invention is described below with reference to requestmanagement flowchart60 illustrated inFIG. 1. First,step61 comprises a request manager receiving a request associated with meta data. Then, instep62, the request manager informs a data object manager of a change in a data object's meta data. The data object manager makes a data object management decision instep63 and, if necessary, acts to implement the data object management decision instep64.

Further aspects of a technique for managing requests associated with data objects in a computer environment in accordance with the present invention are described below with reference toflowchart50 illustrated inFIG. 2. First,step51 comprises a request manager receiving a usage request. Then, if the communications unit is granted permission to use a data object as determined instep52, a request manager sends a request-management message to a data object manager and responds, substantially simultaneously, to a communications unit with a usage-request response in

steps

53 and55, respectively. Subsequent to steps53 and55, respectively, the data object manager prepares for an anticipated request instep54, and data-usage communications are transmitted between the communications unit and data object manager instep56. In one example, the step of transmitting data-usage communications includes transmitting by a communications unit requests for data blocks and transmitting by a data object manager data comprising the requested data blocks of the data object. Alternatively, if the communications unit is not granted permission to use a data object,step57 comprises the request manager responding to a communications unit with a usage-request response.

One example of a communications environment in which a technique for managing requests associated with data objects is utilized in accordance with an aspect of the present invention is described below with reference toFIG. 3. In an environment in which the meta data associated with data objects may be stored separately from the data objects, arequest manager10 receives usage requests from acommunications unit20 viarequest management network12.Request manager10 transmits a request-management message to adata object manager30 via aprivate network14 and responds tocommunications unit20 with a usage-request response viarequest management network12. Ifcommunications unit20 is granted permission to use adata object40, the communications to support use ofdata object40 are transmitted viadata network16 betweencommunications unit20 anddata object manager30.

Generally, both meta data and user data are associated with data objects in a computer communications environment. User data is the information that has meaning to a user or to a program that may process that data. Examples of user data are the contents of a Freelance Graphics® presentation, or employee information stored within a relational database. Meta data is information about user data. Examples of meta data associated with data objects include the identity of client computers that have access permission, data object type, names of files associated with a set of disk blocks, the length of a file, the list of blocks that constitute a file, information about user access permissions, and the date and time a file has been created or updated. Data objects comprise data. Data object types include data files, checkpoint files, file systems, logical volumes, and journaled file system (JFS) logical volume logs.

Features facilitated by use of the technique in the computer environment illustrated inFIG. 3 include: improved security with respect to access to data objects, regulation of the speed of access to data objects, arbitration of access priorities to data objects, and increased speed of access to data objects.

An emerging class of storage environments separates the storage of user data and meta data and provides separate networks over which the user data and meta data traverse. An example of such a storage environment is IBM's Storage Tank™ file system wherein a Storage Tank™ client (a computer) accesses user data from a storage subsystem (over a storage area network (SAN) using block transfer protocols) and accesses meta data from a centralized Storage Tank™ meta data controller (over Ethernet using TCP/IP protocols). The separation of user data and meta data can be either logical or physical. Storage subsystems, which generally comprise a number of disk drives that can be aggregated and made to appear as virtual disk drives to one or more client computers, usually deploy a cache, which is used to hold frequently accessed disk blocks, to improve input-output performance.

One or more aspects of the present invention take advantage of the fact that where user data and meta data are separated, the processing of meta data in conjunction with file access provides additional information which can be used to inform a storage subsystem of future input/output (I/O) access requests. This information can be utilized by a storage subsystem to facilitate the management of its internal caches.

An example of the management of the contents of a cache in a data storage subsystem which utilizes information obtained by processing file meta data in accordance with an aspect of the present invention is described as follows with reference toFIG. 4. When aclient computer210 wants to read and update some disk blocks associated with a file located in astorage subsystem230,client computer210 must be granted an exclusive lock on the associated disk blocks.Client computer210 initiates a transaction tometa data controller220, requesting the lock. This lock request indicates thatclient computer210 intends to perform I/O operations on a certain range of disk blocks in the future. Ifmeta data controller220 can grant the requested lock,meta data controller220 passes a “hint” tostorage subsystem230, which stores those blocks, indicating that the storage subsystem can expect to receive an I/O request from a client computer for a particular range of disk blocks. Meta data controller (MDC)220 communicates this “hint” tostorage subsystem230 viaprivate network222. Essentially concurrently,meta data controller220 grants the lock by signaling toclient computer210 viameta data network212. In this exemplary embodiment,MDC220 is an example of a request manager, andstorage subsystem controller236 ofstorage subsystem230 is an example of a data object manager.

Ifstorage subsystem230 determines that the requested disk blocks are not in cache232, it pre-fetches the requested blocks fromstorage disks234 into cache232. After receiving the requested lock,client computer210 initiates an I/O operation withstorage subsystem230 viadata network214 to access at least some of the disk blocks on which a lock was received. When the client-initiated I/O request is received bystorage subsystem230, the storage subsystem may have the requested disk blocks in its cache already as a result of pre-fetching. If not,storage subsystem230 has already commenced the necessary physical I/O to load the requested blocks into cache232 as a result of previously receiving a hint frommeta data controller220. When the requested disk blocks are available in cache232, they are sent toclient computer210 from cache232 viadata network214. The result ofstorage subsystem230 initiating disk input/output in order to store disk blocks that are subject to a future access request by a client computer in cache232 in advance of receiving a request fromclient computer210 is that data access latency is reduced.

The method of the present invention is also utilized in the operation of the example illustrated inFIG. 4 when a client computer writes disk blocks to the storage subsystem. Ifclient computer210 sends a transaction toMDC220, indicating that the client computer has closed a file and has finished writing blocks to the storage subsystem,meta data controller220 communicates this information tostorage subsystem230 viaprivate network222.Storage subsystem230 determines whether to free the storage locations in cache232 in which the disk blocks comprising the closed file are stored based on this file-closed message and possibly “hints” received regarding other future data access requests. Freeing storage locations in cache232 permits storage of other disk blocks in cache for expedited access.

Another example of managing the contents of a cache in a data storage subsystem which utilizes information obtained by processing file meta data in accordance with an aspect of the present invention relates to a computer writing a large file which is not likely to be read. An example of such a file is a checkpoint/restart file, created by a long-running computational job, or a database log file. These files are typically used to recover the state of a computational workload after a computer crash. Since computer crashes are very rare, checkpoint/restart files are typically written regularly, but rarely read. Knowledge of this information can be used to inform a storage subsystem not to cache a checkpoint/restart file once it has been written to disk.

This example is described further with reference to the exemplary environment ofFIG. 4. Whencomputer210 wishes to write a checkpoint/restart file, it requests write permission frommeta data controller220 via themeta data network212 and informsmeta data controller220 that the file should not be actively cached. Alternatively,meta data controller220 could automatically recognize that the file is of a particular type (such as a checkpoint/restart file).Meta data controller220 grants permission tocomputer210 to write the file, providing a list of blocks where the file should be written, and simultaneously, viaprivate network222, informsstorage controller236 ofstorage subsystem230 thatcomputer210 is about to write a large file that should not be actively cached in storage subsystem cache232.

Whencomputer210 writes the file viadata network214 tostorage subsystem230,storage subsystem controller236 decides how much of cache232 to allocate to storing all or part of the large file and, as quickly as possible, writes the contents of the large file tostorage disks234 within the storage subsystem. As soon as the contents (or partial contents) of the file are written tostorage disks234 of the storage subsystem, the associated file data within the cache232 can be discarded immediately, since it is highly unlikely that this file will need to be read again. Thus, utilization of the cache based on knowledge of the type of data being stored, which is gained through processing the file's meta data, facilitates optimization of the use of the cache resource.

With reference toFIG. 4,computer210 intends to read a checkpoint/restart file socomputer210 requests permission frommeta data controller220 viameta data network212 to read the file and informsmeta data controller220 that the file should not be actively cached. Alternatively,meta data controller220 automatically recognizes that the file is of a particular type (such as a checkpoint/restart file), rather than having to be informed bycomputer210.Meta data controller220 grants permission tocomputer210 to read the file, providing a list of blocks where the file is located, and simultaneously, via theprivate network222, informsstorage subsystem controller236 ofstorage subsystem230 thatcomputer210 is about to read a large file that should not be actively cached in the storage subsystem cache232. Whencomputer210 reads the file viadata network214 fromstorage subsystem230,storage subsystem controller236 decides how much of cache232 to allocate to reading the file fromstorage disks234. As soon as the contents (or partial contents) of the file are transmitted tocomputer210, the associated file data within the cache232 can be discarded immediately, since it is highly unlikely that this file will need to be read again. Thus, utilization of the cache based on the type of data being accessed, which is determined by processing the file's meta data, frees cache resources to facilitate faster access to other files.

Another example of an environment using a technique for managing requests for access to data objects to effectuate management of the contents of a cache in a data storage subsystem by utilizing information obtained from processing file meta data in accordance with an aspect of the present invention is described below with reference toFIG. 5. In this example, a number of computers (310,311, and312) are members of a database cluster. Each of

computers

310,311, and312 hosts an instance of the cluster's database. When acomputer310 wants to read and update some disk blocks associated with a database table located in a storage subsystem330,computer310 must be granted an exclusive lock on the associated disk blocks.Computer310 requests a lock on those disk blocks fromdatabase lock manager320 by sending a request onexternal network314. Ifdatabase lock manager320 can grant the requested lock,database lock manager320 grants the lock via a message sent tocomputer310 onexternal network314 and essentially simultaneously sends a message to storage subsystem330, indicating that the storage subsystem can expect to receive an I/O request from a client computer for a particular range of disk blocks.Database lock manager320 communicates this message to storage subsystem330 viaprivate network322. Analogously to the previous example,database lock manager320 is an example of a request manager, and storage subsystem330 comprises a data object manager.

If storage subsystem330 determines that the disk blocks for which a lock was granted are not incache332, storage subsystem330 initiates an I/O operation tostorage disks334.Computer310 initiates an I/O operation with storage subsystem330 since it has been granted a lock on the requested disk blocks. When the I/O request initiated bycomputer310 is received by storage subsystem330 viadata network316, the storage subsystem may have already pre-fetched the requested disk blocks and stored them incache332. Even if all requested disk blocks have not yet been loaded in the cache, the storage subsystem has initiated the physical I/O fromstorage disks334 prior to receiving the request fromcomputer310. As a result, the latency in providing the requested disk blocks fromcache332 is less than it would be without pre-fetching prompted by the “hint” from the database lock manager.

In another example of a computer environment embodying the present invention, which is described with reference toFIG. 6, a centralized storagemeta data controller434 is co-hosted with astorage subsystem420. In this environment, one or more computers are connected to the data storage subsystem via a data network. By way of example, as shown inFIG. 6, a computer410 exchanges data with astorage subsystem420 viadata network412.Storage subsystem420 comprises a server430 connected to acache322 andstorage disks424. Server430 compriseslogical partitions431 and432.

In this example, the functions ofmeta data controller434 andstorage subsystem controller433 are executed by software running in logical partitions (LPARs)432 and431, respectively, of server430. Using virtual input/output bus436 between the metadata controller LPAR432 and the storage subsystem controller LPAR431, “hints” regarding anticipated future I/O requests directed tostorage subsystem420 are passed at very high speed and low latency frommeta data controller434 tostorage subsystem controller433. The benefit of pre-fetching disk blocks into the storage subsystem cache is enhanced by the use of high-speed, low-latency communications between the meta data controller and storage subsystem controller. In this example,meta data controller434 andstorage subsystem controller433 are examples of a request manager and a data object manager, respectively.

The present invention can be included in an article of manufacture (e.g., one or more computer program products) having, for instance, computer usable media. The media has therein, for instance, computer readable program code means or logic (e.g., instructions, code, commands, etc.) to provide and facilitate the capabilities of the present invention. The article of manufacture can be included as a part of a computer system or sold separately.

Additionally, at least one program storage device readable by a machine embodying at least one program of instructions executable by the machine to perform the capabilities of the present invention can be provided.

The flow diagrams depicted herein are just examples. There may be many variations to these diagrams or the steps (or operations) described therein without departing from the spirit of the invention. For instance, the steps may be performed in a differing order, or steps may be added, deleted or modified. All of these variations are considered a part of the claimed invention.

Although preferred embodiments have been depicted and described in detail herein, it will be apparent to those skilled in the relevant art that various modifications, additions, substitutions and the like can be made without departing from the spirit of the invention and these are therefore considered to be within the scope of the invention as defined in the following claims.

Claims

1. A method of managing requests in a communications environment, said method comprising:

receiving by a manager a request associated with meta data, said meta data corresponding to data maintained separately from the meta data; and

informing, by the manager, another manager of an anticipated request to be received by the another manager to enable the another manager to prepare for the anticipated request.

2. The method ofclaim 1, further comprising preparing by the another manager for the anticipated request, said preparing responsive to said informing.

3. The method ofclaim 2, wherein said preparing comprises managing contents of a cache in a data storage subsystem.

4. The method ofclaim 2, wherein said preparing comprises managing a user's or a client computer's access to the data.

5. The method ofclaim 2, further comprising:

sending, by the manager, a reply to a communications unit in response to the request substantially simultaneously with said informing; and

receiving, by the another manager, the anticipated request, wherein said preparing begins before the receiving by the another manager.

6. The method ofclaim 3, wherein said managing contents comprises pre-fetching one or more data blocks from one or more storage media of the data storage subsystem whereby the data blocks are stored in the cache, the data blocks comprising at least some of the data.

7. The method ofclaim 3, wherein said managing contents comprises releasing storage locations of the cache whereby the storage locations become available for storing other data, the storage locations storing data blocks comprising at least some of the data.

8. A request management system for a communications environment, said system comprising:

means for receiving by a manager a request associated with meta data, said meta data corresponding to data maintained separately from the meta data; and

means for informing, by the manager, another manager of an anticipated request to be received by the another manager to enable the another manager to prepare for the anticipated request.

9. The system ofclaim 8, further comprising means for preparing by the another manager for the anticipated request, said means for preparing responsive to said means for informing.

10. The system ofclaim 9, wherein said means for preparing comprises means for managing contents of a cache in a data storage subsystem.

11. The system ofclaim 9, wherein said means for preparing comprises means for managing a user's or a client computer's access to the data.

12. The system ofclaim 9, further comprising:

means for sending, by the manager, a reply to a communications unit in response to the request substantially simultaneously with informing the another manager of the anticipated request to be received; and

means for receiving, by the another manager, the anticipated request, wherein said means for preparing begins prepare for the anticipated request before the means for receiving receives the anticipated request.

13. The system ofclaim 10, wherein said means for managing contents comprises means for pre-fetching one or more data blocks from one or more storage media of the data storage subsystem whereby the data blocks are stored in the cache, the data blocks comprising at least some of the data.

14. The system ofclaim 10, wherein said means for managing contents comprises means for releasing storage locations of the cache whereby the storage locations become available for storing other data, the storage locations storing data blocks comprising at least some of the data.

15. At least one program storage device readable by a machine embodying at least one program of instructions executable by the machine to perform a method of managing requests in a communications environment, said method comprising:

16. The at least one program storage device ofclaim 15, wherein said method further comprises preparing by the another manager for the anticipated request, said preparing responsive to said informing.

17. The at least one program storage device ofclaim 16, wherein said preparing comprises managing contents of a cache in a data storage subsystem.

18. The at least one program storage device ofclaim 16, wherein said preparing comprises managing a user's or a client computer's access to the data.

19. The at least one program storage device ofclaim 16, wherein said method further comprises:

20. The at least one program storage device ofclaim 17, wherein said managing contents comprises pre-fetching one or more data blocks from one or more storage media of the data storage subsystem whereby the data blocks are stored in the cache, the data blocks comprising at least some of the data.