WO2018116453A1

WO2018116453A1 - Access system and access method

Info

Publication number: WO2018116453A1
Application number: PCT/JP2016/088433
Authority: WO
Inventors: 涼澤井
Original assignee: 株式会社日立製作所
Priority date: 2016-12-22
Filing date: 2016-12-22
Publication date: 2018-06-28

Abstract

[Problem] To make it possible to suppress the accumulation of a large volume of ISV-defined API commands, issued by a management server in a short time, in a plug-in server, and to enable the plug-in server to efficiently issue a storage API command. [Solution] A command relay device in which an integration control unit, in response to a storage device having reached a specific state in which a lower-level-side command is difficult to be accepted, shifts to a unified transmission mode in which, on the basis of a command correspondence management table that manages a correspondence relationship between higher-level-side commands and lower-level-side commands for a predetermined period, a unification process for unifying higher-level-side commands received from a higher-level device and converting the commands into a lower-level-side command can be executed, and issues the unified lower-level-side command to the storage device.

Description

Access system and access method

The present invention relates to an access system and an access method, and in particular, an access including a relay device for relaying data between a storage device capable of storing data and a host device that reads / writes data from / to the storage device. It is suitable for application to a system.

In recent years, server software (hereinafter referred to as “management server”) provided by ISVs (Independent Software Vendors) other than storage device vendors, as represented by VMWare's VVOL (Virtual Volume), for example, is a specific storage device vendor. A solution has been established that makes it possible to use a high-speed and highly reliable copy function, backup function, and the like included in the storage apparatus.

The management server issues an ISV definition API command to the storage apparatus, but the storage apparatus can accept only the storage API command. For this reason, a plug-in server as a command relay device equipped with an API command conversion function for converting an ISV definition API command into a storage API command is provided between the management server and the storage device. Even if the server and the storage apparatus are provided from different vendors, the function of the storage apparatus can be directly controlled from the management server (see Patent Document 1).

Japanese Patent No. 4701267

In such a conventional technique, there is a limitation on the upper limit number of storage API commands that can be processed simultaneously on the storage device side. Therefore, when the management server issues a large number of ISV definition API commands in a short time, a plug-in The server may not be able to issue the storage API command. As a result, a large amount of the ISV definition API command cannot be processed in the plug-in server and stays, and as a result, when viewed from the management server, the result of the ISV definition API command may not be returned. .

The present invention has been made in consideration of the above points, and suppresses a large amount of ISV definition API commands issued by the management server within a short time from staying in the plug-in server, and the plug-in server issues a storage API command. It is an object of the present invention to propose an access system and an access method that can be issued efficiently.

In order to solve such a problem, the access system according to the present invention includes a host device that issues a higher-order command related to data writing and reading, new creation / deletion / change of a data storage area, etc., and the host device received from the host device. A command relay apparatus operable in a normal mode for converting a side command into a low-order command in a 1: N ratio (N ≧ 1), and writing and reading of data and data storage according to the low-order command received from the command relay apparatus A storage device capable of newly creating / deleting / changing an area, etc., wherein the command relay device manages a correspondence relationship between the upper command and the lower command, and the storage device Triggered a specific state where it is difficult to accept the lower-order command. , Based on the command correspondence management table over a predetermined period, shift to a collective throw mode that can execute processing for collectively converting the higher-order commands received from the higher-order device to the lower-order command, And an integrated control unit that issues a side command to the storage device.

Also, the host device that issues higher-order commands related to writing and reading of data and new creation / deletion / change of the data storage area in the present invention and the higher-order commands received from the higher-order device on a one-to-one basis In an access method in an access system, comprising: a command relay device operable in a normal mode for converting to a command; and a storage device capable of writing and reading the data according to the lower-order command received from the command relay device. The command relay device manages a correspondence relationship between the upper command and the lower command over a predetermined period when the storage device has reached a specific state in which it is difficult to accept the lower command. Based on the correspondence management table, Together the upper side commands between the received shifted to collectively throw mode to convert to the lower-side command, and executes an integrated control step of issuing the lower command to the storage device.

According to the present invention, it is possible to prevent a large number of higher-order commands issued by the higher-level device within a short time from staying in the command relay device, and the command-relay device can efficiently issue lower-order commands.

It is a block diagram which shows the hardware structural example of the access system by this Embodiment. It is a block diagram which shows the software structural example of the access system by this Embodiment. It is a figure which shows the structural example of a lump throw flag management table. It is a figure which shows the structural example of a command conversion table. It is a figure which shows the table structural example of a lump throw API conversion table. It is a figure which shows the structural example of a storage API processing time table. It is a state transition diagram which shows a mode that each mode by a plug-in server changes. It is a flowchart which shows an example of the judgment process of collective throwing mode. It is a sequence chart showing the state of each mode in which the plug-in of a plug-in server can change. It is a sequence chart which shows an example of the fixed time weight system as a comparative example. It is a sequence chart which shows an example of the system by this Embodiment. It is a sequence chart which shows an example of a wait time learning system. It is a sequence chart which shows an example of the system by this Embodiment.

Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

(1) Configuration of Access System According to this Embodiment (1-1) Hardware Configuration FIG. 1 shows an example of the hardware configuration of each device constituting the access system according to this embodiment. The access system according to the present embodiment includes an upper server 100, a plug-in server 200, and a storage device 301. The upper server 100 is an example of an upper device, and the plug-in server 200 is an example of a command relay device.

(1-1-1) Host device (host server)
The host server 100 includes a CPU 100A, a RAM 100B, a ROM 100C, a disk device 100D, and a NIC 100E. In the CPU 100A, the firmware read from the ROM 100C and the operating system read from the disk device 100D operate on the RAM 100B. The disk device 100D can store various programs and data in addition to the operating system. The NIC 100E is an interface with the network 150.

On the upper server 100, management server software (hereinafter referred to as “management server”) 101 that performs a server function operates on the operating system under the control of the CPU 100A. Details of the management server 101 will be described later.

(1-1-2) Command relay device (plug-in server)
Since the plug-in server 200 is a kind of computer and has almost the same configuration as the upper server 100, the description will focus on the differences from the upper server 100. The plug-in 201 includes a CPU 200A, a RAM 200B, a ROM 200C, a disk device 200D, and a NIC 200E. The plug-in server 200 includes an interface (corresponding to the IF shown) 200 </ b> F for exchanging with the storage apparatus 301 as a configuration not included in the upper server 100.

(1-1-3) Storage Device The storage device 301 is connected to the plug-in server 200 via the network 250. The storage apparatus 301 includes a disk controller 301B having a predetermined number of receiving slots 301A (corresponding to “slots” in the figure) and a disk drive 301C. In the present embodiment, such a predetermined number of reception slots 301A are also expressed as “queues”. The disk drive 301C is a kind of storage device that can store data by a so-called RAID system.

Each reception slot 301A stores a storage API command, and each storage API command is erased when a corresponding data read or write process or new creation / deletion / change of a data storage area such as a so-called LUN is completed.

The disk controller 301B controls the update, write, and read of data with the disk drive 301C according to each storage API command written in each reception slot 301A, and manages the data inside the disk controller 301B. The storage area management table 301D is created, deleted, changed, etc., and when the control corresponding to each storage API command is completed or an error occurs, a response corresponding to the response is sent to the upper server 100 via the plug-in server 200. .

(1-2) Software Configuration FIG. 2 shows a software configuration example of the access system according to the present embodiment. In the following description, software related to the present embodiment will be mainly described.

(1-2-1) Overview of the Host Server On the host server 100, the management server 101, which is ISV vendor software, is operating. The management server 101 includes an ISV definition API issuing IF 102. In the management server 101, the ISV definition API issuing IF 102 has a function of issuing an ISV definition API command (higher-order command) for reading and writing data with the storage apparatus 301.

(1-2-2) Overview of Plug-in Server The plug-in 201 is operating on the plug-in server 200. The ISV vendor described above is different from the vendor of the storage apparatus 301. Therefore, the plug-in 201 converts the command issued by the management server 101 into a storage API command (lower-order command) and outputs it to the storage apparatus 301. This storage API command newly writes data to the storage device 301, reads, updates, or deletes data stored in the storage device 301, and creates and deletes a data storage area such as a so-called LUN. , A control command for updating and the like.

In the plug-in 201, the ISV definition API issuing IF 204 is operating. The ISV definition API issuance IF 102 of the plug-in 201 issues an ISV definition API command to the ISV definition API issuance IF 204 of the plug-in 201 and waits for a response from the ISV definition API issuance IF 204.

The queue management unit 206 receives the ISV definition API command from the ISV definition API issue IF 204 and accumulates it. The queue management unit 206 includes a collective throw flag management table 206A shown in FIG.

The collective throw flag management table 206A includes, for example, an ISV definition API command 206AA and a collective throw flag 206AB corresponding to the ISV definition API command 206AA as columns, and manages the correspondence between them.

In the collective throw flag management table 206A, the collective throw flag 206AB is associated with the ISV definition API command and managed as follows according to the state of the collective throw flag 206AB. That is, the ISV definition API command registered as the ISV definition API command 206AA in which the collective throw flag 206AB is set to “1” indicates that the ISV definition API command is an accumulation target.

On the other hand, the ISV definition API command in which the collective throw flag 206AB is set to “0” in the ISV definition API command 206AA indicates that the ISV definition API command is not an accumulation target.

In the present embodiment, setting the collective throw flag corresponding to the ISV definition API command from “0” to “1” is also expressed as “associating (or attaching) the collective throw flag to the ISV definition API command”. To do.

In the present embodiment, as an example, the queue management unit 206 temporarily sets the collective throw flag to “0” for all ISV definition API commands received from the upper server 100.

The integrated control unit 202 sets the collective throw flag to “1” only for the ISV definition API command to be processed in the collective throw mode in the command accumulation mode and collective throw mode described later.

The user interface 210 accepts the setting of an execution schedule for a monitoring process to be described later according to a user input operation. For example, an execution schedule such as every hour or every day of the week is set. If no execution schedule is specified, a default execution schedule prepared in advance is used. The user interface 210 stores a setting of an execution schedule for a monitoring process described later in the scheduler unit 209. In other words, the scheduler unit 209 manages settings related to the execution schedule of this monitoring process.

On the other hand, the storage API processing time table 208 manages the processing time in the storage apparatus 301 corresponding to each storage API command. The integrated control unit 202 measures the processing time of each storage API command a plurality of times and stores the processing time of each storage API command obtained through arbitrary statistical processing such as processing for obtaining an average value, for example, in the storage API processing time table 208. To record. Note that the initial value of the processing time in the storage API processing time table 208 may be arbitrary.

The command conversion table 203 defines the target storage API command to be converted from the ISV definition API command on a one-to-one basis. Details of the command conversion table 203 will be described later.

The collective throwing API conversion table 207 is a command capable of executing a process (hereinafter referred to as “collective throwing process”) in which a plurality of ISV definition API commands are gathered into one and transmitted to the storage apparatus 301 as one storage API command. Define the correspondence between each other. Details of the collective throwing API conversion table 207 will be described later.

The storage AP issue IF 205 issues a storage API command to the storage API command IF 302. Details of the plug-in server 200 will be described later.

(1-2-3) Outline of Storage Device The storage device 301 is equipped with a storage API command IF 302. The storage device 301 executes data writing and reading according to the converted storage API command. The storage API command IF 302 has N_max as the upper limit value of the number of storage API commands that can be processed simultaneously according to the total number of the reception slots 301A described above.

(2) Table Configuration (2-1) Command Conversion Table FIG. 4 shows a configuration example of the command conversion table 203. The command conversion table 203 manages the correspondence between the ISV definition API command from the upper server 100 and the storage API command to be converted as a command for the storage apparatus 301 in correspondence with the ISV definition API command.

The command conversion table 203 has, for example, an ISV definition API command 203A and a storage API command 203B as its columns. The ISV definition API command 203A represents an ISV definition API command as an example of a higher-level command issued by the management server 101. On the other hand, the storage API command 203B represents a storage API command as an example of a lower-order command to be converted for the storage apparatus 301 for each ISV definition API command issued by the management server 101.

(2-2) Collective Throw API Conversion Table FIGS. 5A and 5B show table configuration examples of the collective throw API conversion table. FIG. 5A shows a state before changing the processing order of a plurality of storage API commands, and FIG. 5B shows a state after changing the processing order of the plurality of storage API commands.

The collective throwing API conversion table 207 is used as a storage API command, instead of converting into a storage API command one-on-one among a large number of ISV definition API commands issued by the management server 101. It manages combinations of ISV definition API commands that can be converted. Therefore, ISV definition API commands of a type not managed in the collective throwing API conversion table 207 are converted into storage API commands on a one-to-one basis.

In the present embodiment, as an example, the collective throw API conversion table 207 is an ISV definition API that can convert two ISV definition API commands out of many types of ISV definition API commands into one storage API command. It manages the correspondence between command combinations and the converted storage API commands. In addition, the collective throw API conversion table 207 also manages command dependency relationships between storage API commands to be issued successively.

When the integrated control unit 202 receives the ISV definition API command from the management server 101 in the collective throw mode, the integrated control unit 202 refers to the collective throw API conversion table 207, and the ISV definition API command is received in the collective throw mode. It is determined whether the storage API command can be generated together with the ISV definition API command. In this way, depending on the type of ISV definition API command issued by the management server 101, it is more efficient to issue a storage API command out of a number of ISV definition API commands, or not. And the processing efficiency can be improved.

As shown in FIG. 5A, the collective throw API conversion table 207 includes, as its columns, a first ISV definition API command 207A, a second ISV definition API command 207B, a storage API command 207C, and a command dependency 207D. Have

In the collective throwing API conversion table 207, as the first record, for example, the first ISV definition API command 207A is “I_API_A (a)” and the second ISV definition API command 207B is “I_API_A (b)”. The storage API command 207C is “S_API_1 (a, b)”.

Note that “S_API_2 (a, b)” also exists in the storage API command 207C in the same record. At first glance, two ISV definition API commands are converted into two storage API commands, so the commands are not collected. Although it is also illustrated in the figure, originally four storage APIs S_API_1 (a), S_API_2 (a), S_API_1 (b), and S_API_2 (b) are issued, S_API_1 (a, b), Note that the two storage APIs of S_API_2 (a, b) are collected. The same applies to the second record and the third record following the first record in the collective throwing API conversion table 207 shown in the figure.

(2-3) Storage API Processing Time Table FIG. 6 shows a configuration example of the storage API processing time table 208. The storage API processing time table 208 includes, for example, a storage API command 208A and a processing time 208B as its columns.

The storage API command 208A represents the name of each storage API command. On the other hand, the processing time 208B represents the processing time [s] when each storage API command is processed in the storage apparatus 301.

In the illustrated example, the storage API command “S_API_2” is 2.000 [s], and the processing is completed in the longest processing time, while the storage API command “S_API_1” is 0.001 [s]. The processing can be completed in the shortest processing time.

(2-4) Monitoring processing In the present embodiment, as shown in the following items (2-4-1) to (2-4-4), based on the result of monitoring the storage API command processing time A mode for dynamically changing the registered contents of the collective throwing API conversion table 207 is added. As a result of these measures, fluctuations in storage API command processing time caused by differences in processing time (difference between day and night processing) and environment dependence (number of connected servers, network environment, disk configuration in storage, etc.) The purpose is to issue storage API commands in a more optimal order according to the difference, and to process some ISV definition API commands faster.

Specifically, the storage API processing time table 208 and the collective throwing API conversion table 207 are dynamically changed as follows.

Processing time zone (difference between daytime and nighttime processing): Since many ISV_API commands are issued during business hours in the daytime, the storage load is concentrated and the processing time of the storage API becomes longer, but at the night, the ISV_API command is issued In a situation where the processing time of the storage API is shortened due to a small amount of data, the integrated control unit 202 moves the storage API processing time table 208 and the collective throwing API conversion table 207 before, for example, the early morning business start time and the midnight time zone. To change it.

Dependent on environment: Changes in the number of servers connected to the storage device 301 (consolidation and expansion) during business start, changes in the network environment, and dynamic changes in the disk configuration in the storage device 301 (for example, SAS HDD to Flash memory, etc.) The actual processing time of the storage API command may change due to an environmental change event such as a change to a high-speed disk or vice versa, or an increase in the processing speed due to a micro update of the storage device 301 or the like. is there. Even in such a case, after the environment changes, the integrated control unit 202 responds by dynamically changing the storage API processing time table 208 and the collective throwing API conversion table 207.

(2-4-1) Initial State Rule Setting Processing In this embodiment, the batch throw API conversion table 207 holds the following rule information in the initial state.
・ Bullet throwing rules:
For example, the storage API command S_API_1 (a, b) is a target of batch throw processing.
-Storage API command issue dependency rules:
For example, before issuing the storage API command S_API_2, the processing of another storage API command S_API_1 having a dependency relationship is completed.

Further, a storage API processing time table 208, a scheduler unit 209, and a user interface 210 are added to the plug-in 201. Note that the initial value of the processing time in the storage API processing time table 208 may be arbitrary.

(2-4-2) Command processing time recording process As described above, in the plug-in 201, the integrated control unit 202 measures the processing time of each storage API command a plurality of times, and for example, obtains an average value. The processing time of each storage API command obtained by executing such arbitrary statistical processing is recorded in the storage API processing time table 208.

(2-4-3) Issuance Order Replacement Processing The integrated control unit 202 refers to the storage API processing time table 208, determines the issuance order of storage API commands registered in the batch throw API conversion table 207, and sets the command dependency relationship. In a range that can be maintained, replacement is performed so that the one to be processed first, for example, the one with the short processing time comes first. This makes it possible to postpone the completion of time-consuming ISV definition API commands later and to complete some ISV definition API commands preferentially.

First, in an example in which the issue order change process according to the present embodiment shown in FIG. 5A is not executed, the storage API command S_API_2 (a), which is a time-consuming process, is completed for the ISV definition API command I_API_C (a). I had to wait until. On the other hand, in the example of executing the issue order change processing according to the present embodiment shown in FIG. 5B, the storage API command S_API_1 (a, b), the storage API command S_API_4 (b), and the storage API command S_API_5 ( By executing b) before the storage API command S_API_2 (a), it is possible to return the response of the ISV definition API command I_API_C (b) to the upper management server 101 first.

(2-4-4) Monitoring process (2-4-4-1) Overview of monitoring process The integrated control unit 202 combines the above-described initial state rule setting process, command process time recording process, and issue order change process. The “monitoring process” is executed independently regardless of which mode is selected from the normal mode, the command accumulation mode, and the collective throwing mode. The integrated control unit 202 executes this monitoring process triggered by any one of the following first time points and second time points.

(2--4-4-2) Monitoring Processing Execution Timing As the first time point, the integrated control unit 202 periodically polls the scheduler unit 209 and sets the schedule setting time stored in the scheduler unit 209. It is the time when it was judged that it became.

As the second time point, the scheduler unit 209 monitors the setting relating to the execution schedule of the monitoring process held by itself, and notifies the integrated control unit 202 of the instruction for the monitoring process when the set time is reached. Is the point of time.

(3) Modes by Plug-in Server (3-1) Mode Types FIG. 7 shows a state transition diagram of each mode by the plug-in server 200. In the plug-in server 200, the integrated control unit 202 can transition to any of the normal mode, the command accumulation mode, and the collective throw mode, for example.

(3-1-1) Normal Mode In the normal mode, the integrated control unit 202 reads out the ISV definition API command from the queue management unit 206, and, according to the command conversion table 203, single or plural corresponding to the ISV definition API command. To the storage API command. The integrated control unit 202 delivers the converted storage API command to the storage API command IF 205 and issues it to the storage apparatus 301, and waits for a response from the storage API command IF 302 of the storage apparatus 301.

(3-1-2) Command Accumulation Mode In the command accumulation mode, the integrated control unit 202 manages the ISV definition API command to be accumulated in the queue management unit 206 in association with the collective throw flag. That is, the integrated control unit 202 sets the collective throw flag corresponding to the ISV definition API command stored in the queue management unit 206 from “0” to “1”. In this command accumulation mode, the integrated control unit 202 suspends the conversion of the ISV definition API command into the storage API command and the transmission of the converted storage API command to the storage apparatus 301.

(3-1-3) Collective Throw Mode In the collective throw mode, the integrated control unit 202 determines whether or not the ISV definition API command associated with the collective throw flag exists in the queue management unit 206. The integrated control unit 202 sets the combinations defined in the collective throw API conversion table 207 for all ISV definition APIs whose collective throw flag of the ISV definition API command registered in the queue management unit 206 is “1”. Transmits the storage API commands corresponding to the storage API commands together via the storage API command IF 205. On the other hand, for the ISV definition API that is not defined in the collective throw API conversion table 207, the corresponding storage API is issued with reference to the command conversion table 203. Details of the collective throwing process will be described later.

(3-2) Transition Conditions for Each Mode In this embodiment, the transition conditions for each mode are as follows.
(3-2-1) Normal Mode → Command Accumulation Mode In the plug-in 201, when the response to the storage API command issued by the integrated control unit 202 via the storage API command IF 205 is a busy response or the like, The number of storage APIs) is determined to be N_max, and the normal mode is changed to the command accumulation mode.

(3-2-2) Command Accumulation Mode → Batch Throw Mode In the plug-in 201, in response to the integration control unit 202 receiving a response to the storage API command that has already been processed, the integration control unit 202 ( The number of storage APIs being processed) is determined to be <N_max, and the command accumulation mode is changed to the collective throwing mode.

(3-2-3) Collective throwing mode → normal mode In the plug-in 201, the integrated control unit 202 satisfies (the number of storage API commands being processed) <N_max and the collective throwing target flag is set in the queue management unit 206. When it is determined that the ISV definition API command of “1” does not exist, the collective throwing mode is changed to the normal mode.

(3-3) Processing Procedure in the Collective Throw Mode FIG. 8 is a flowchart showing an example of the processing procedure in the collective throw mode.
In the collective throwing mode in this embodiment,
Number of commands during execution of storage API command = N_proc
Number of storage API command reception maximum queues (corresponding to the reception slot 301A) = N_max
In this case, the integrated control unit 202 sets N_proc = N_max-1 at the start of the collective throwing mode (step S101). The integrated control unit 202 determines whether there is a response to the storage API command being processed (step S102).

The integrated control unit 202 reduces the value of N_proc by 1 (step S103). If all storage API commands corresponding to the ISV definition API command have been completed, the integrated control unit 202 returns a response to the ISV definition API command to the management server 101 and deletes the ISV definition API command from the queue management unit 206. (Step S104).

The integrated control unit 202 determines whether or not N_max> N_proc is satisfied (step S105).

When N_max ≦ N_proc (ie, N_max = N_proc) (step S105), the integrated control unit 202 determines whether or not the ISV definition API command further received from the management server 101 exists in the queue management unit 206. (Step S106).

When the integrated control unit 202 further receives an ISV definition API command from the management server 101, the integrated control unit 202 registers the batch throw flag in association with the queue management unit 206 (step S107), and returns to step S102 described above. If, on the other hand, no ISV definition API command has been received from the management server 101, the process returns to step S102 described above to execute it.

On the other hand, if N_max> N_proc (step S105), the integrated control unit 202 operates as follows depending on whether or not the ISV definition API command associated with the collective throw flag exists in the queue management unit 206.

A) The integrated control unit 202 determines whether there is an ISV definition API command associated with the collective throw flag in the queue management unit 206 (step S108).

When there is an ISV definition API command associated with the collective throw flag in the queue management unit 206, the integrated control unit 202 performs a collective throw API conversion table for the ISV definition API command associated with the collective throw flag. For the combinations defined in 207, the corresponding storage API commands are collected together and transmitted via the storage API command IF 205. For the ISV definition APIs not defined in the collective throwing API conversion table 207, the command conversion table 203 is used. The corresponding storage API is referred to and transmitted to the storage apparatus 301 via the storage API command IF 205 (step S109), and N_proc = N_proc + 1 is set (step S110).

B) When there is no ISV definition API command associated with the collective throw flag in the queue management unit 206 (step S108), the integrated control unit 202 shifts to the normal mode.

(3-4) Each Command Delivery State in Each Mode FIG. 9 is a sequence chart showing an example of each command delivery state in each mode in which the plug-in 201 of the plug-in server 200 can transition. The names shown on the arrows connecting the management server 101 and the plug-in 201 represent the names of the ISV definition API commands shown in FIG. 3 to FIG. The names illustrated on the arrows connecting the storage devices 301 represent the names of the storage API commands illustrated in FIGS. 4, 5, and 6, respectively.

A) Switching from normal mode to command accumulation mode The mode is switched when an error response of the storage API command is returned. In addition to the error that the accepting slot 301A is full, the present invention can be applied to any error that seems to be a temporary error caused by the storage device 301 such as a response temporarily impossible due to a heavy load.

It should be noted that an error such as a failure of the storage device 301 that seems to be permanent or an error such as an invalid argument of the storage API command is not expected to be recovered even after a wait period, and therefore, this embodiment performs a collective throw process. It is not an opportunity to execute.

In the command accumulation mode, the integrated control unit 202 manages the ISV definition API command to be accumulated in the queue management unit 206 in association with the collective throw flag, and converts the ISV definition API command into a storage API command. The storage API command after the conversion is suspended.

B) Switching from command accumulation mode to batch throwing mode Switching is performed when one of the storage APIs already processed in the storage apparatus 301 returns from the normal response before shifting to the command accumulation mode.

In the collective throwing mode, the integrated control unit 202 converts the ISV definition API command associated with the collective throwing flag managed by the queue management unit 206 into a storage API according to the collective throwing API conversion table 207, and the storage API command. Issued to the storage apparatus 301 through the IF 205.

In the collective throwing mode, it is assumed that there is no empty reception slot 301A in the storage device 301. Therefore, the integrated control unit 202 gives priority to the completion of the ISV definition API command associated with the collective throwing flag, and the collective throwing mode If the ISV definition API is received from the management server, the ISV definition API is retained in the queue management unit 206 in the plug-in 201 until the normal mode is entered.

C) Switching from collective throw mode to normal mode The integrated control unit 202 switches from the collective throw mode to the normal mode when all responses are returned from the access system for the storage API command group executed in the collective throw mode.

In the normal mode, the integrated control unit 202 converts the ISV definition API command entered in the queue management unit 206 into a storage API command with reference to the command conversion table 203 and issues it to the storage apparatus 301 through the storage API command IF 205.

(3-5) State until the queue is full As described above, in the normal mode, the integrated control unit 202 has received a temporary storage API command error as a response from the storage apparatus 301. Judging. When an error of the storage API command is returned from the storage apparatus 301, the integrated control unit 202 transitions from the current normal mode to the command accumulation mode.

(3-6) When queue is full As a method of setting a time zone (wait time) in which the queue is full and new ISV definition API command processing cannot be accepted, the following method may be used. It goes without saying that the wait time may be set according to the number of storage API commands received in the receiving slot (queue) 301A instead of the following.

In the present embodiment, the start and end of the period from the start of the wait to the end of the wait (corresponding to the “wait time”) is devised so as to be triggered by, for example, the following events.
Wait start: An error indicating that a storage API command cannot be accepted has occurred. End of wait: A normal end has been returned for any of the storage API commands being processed. The following are excellent.

(3-6-1) Method with fixed time from start of wait to end of wait (Part 1)
In the case of the fixed time wait method as the comparative example shown in FIG. 10, for example, if it is attempted to secure a long wait time so that the collective throwing process is possible, after the number of processing storage API commands becomes N−1. There is also a possibility that useless waiting time will come out. As a result, there is a possibility that the timing for starting the collective throwing process is delayed as shown in the figure.

On the other hand, in the present embodiment shown in FIG. 11, there is no useless waiting time, and it is possible to immediately end the waiting time and start the collective throwing process immediately. In addition, processing overhead can be seen. On the other hand, in the fixed time wait method as the comparative example shown in FIG. 11, if the wait time is shortened, the number of storage API commands to be subjected to the collective throwing process is reduced, and the speedup by the collective throwing process is increased. There is a risk that it will be difficult to obtain the effect.

Further, when the wait time is simply changed according to the number of storage API commands being processed, or when the wait time is always set regardless of the number of storage API commands being processed (that is, the batch throw mode is always set). Equivalent) can also be considered to cause similar problems at first glance.

(3-6-2) Method of learning wait time from past statistical information (part 2)
Therefore, in the plug-in 201, the integrated control unit 202 counts the number of commands of the current processing storage API command, and immediately before the storage processing in progress as in the wait time learning method as the comparative example shown in FIG. It is also possible to adopt a method in which the return time from the storage apparatus 301 is learned in advance for the storage API for which the number of API commands = N, and that time is used as the wait time.

However, in the end, the execution of the collective throwing process after the response to the storage API command S_API_X (1) in FIG. 12 is the same in the present embodiment, and as a result, the storage API command group that is the target of the collective throwing process. The number of commands does not change. In such a wait time learning method, the following points should be noted.

The wait time learning shown in FIG. 12 is used for reasons other than when the receiving slot 301A is full of storage API commands (for example, a busy error response that is because the storage device 301 is temporarily unable to respond, such as when the storage device 301 is heavily loaded). The method may not be able to handle it. On the other hand, the system according to the present embodiment shown in FIG. 13 can cope with this.

In the wait time learning method shown in FIG. 12, it is sufficient if there is a response to the storage API command S_API_X (1), but if there is another response to another storage API command being processed, the wait time can be unnecessarily long. There is sex. That is, processing overhead may be visible. However, in the method according to the present embodiment, any one of the storage API commands that are being processed only needs to be responded, and thus the above-described inconvenience can be dealt with.

 Since there is no need to execute the learning process, the present embodiment simply simplifies with fewer mounting steps. Thereby, it becomes easy to perform maintenance, and the risk of occurrence of defects can be reduced.

According to the present embodiment as described above, a large amount of ISV definition API commands issued by the management server 101 within a short time is prevented from staying in the plug-in server 200, and the plug-in server 200 is stored in the storage apparatus 301. On the other hand, it is possible to efficiently issue a storage API command.

(4) Other Embodiments The above embodiment is an example for explaining the present invention, and is not intended to limit the present invention only to these embodiments. The present invention can be implemented in various forms without departing from the spirit of the present invention. For example, in the above-described embodiment, the processing of various programs is described sequentially, but this is not particularly concerned. Therefore, as long as there is no contradiction in the processing result, the processing order may be changed or the operation may be performed in parallel.

(4-1) Modified Example of Switching Trigger from Normal Mode to Command Accumulation Mode The integrated control unit 202 has other triggers other than the trigger that has reached the state where the reception slot 301A of the storage device 301 is full (specific state). The following mode switching opportunity may be adopted.

(4-1-1) Method 1
In the plug-in 201 of the plug-in server 200, the integrated control unit 202 monitors, for example, the number of commands issued per unit time as throughput in the normal mode, and the command issuance number per unit time is set in advance. When the specified value is exceeded, the mode shifts from the normal mode to the command accumulation mode. In this way, it is possible to grasp that the command storage mode should be shifted to in the future at an earlier stage, and therefore it is possible to shift to the command storage mode at a more appropriate timing without useless time lag.

(4-1-2) Method 2
In the plug-in 201 of the plug-in server 200, the integrated control unit 202 determines that the number of storage API commands that are simultaneously executed in the storage apparatus 301 in the normal mode is the predetermined number of storage API commands that can be executed simultaneously in the storage apparatus 301. In other words, the fact that (the number of storage API commands being executed simultaneously in the storage apparatus 301)> N_max × a (where 0 <a ≦ 1.0) is satisfied. As an opportunity, the normal mode may be shifted to the command accumulation mode.

According to the above-described modified example method, it is possible to detect that a large number of ISV definition API commands are issued earlier and to shift to the command accumulation mode at an earlier timing, thereby further improving the efficiency of the collective throwing process. Can be achieved.

The present invention can be widely applied to an access system including a storage device that can store data and a relay device that relays data between the storage device and a host device that reads / writes data from / to the storage device.

DESCRIPTION OF SYMBOLS 100 ... Host server, 101 ... Management server, 200 ... Plug-in server, 201 ... Plug-in, 202 ... Integrated control unit, 203 ... Command conversion table, 204 ... ISV definition API issue IF, 205 ... ... Storage API command IF, 206 ... Queue management unit, 207 ... Batch throw API conversion table, 208 ... Storage API processing time table, 301 ... Storage device, 301A ... Reception slot, 301B ... Data storage area management Table 302... Storage API command IF.

Claims

A higher-level device that issues higher-level commands related to data writing and reading;
A command relay device operating in a normal mode for converting the higher order command received from the higher order device into a lower order command on a one-to-one basis;
A storage device capable of writing and reading the data according to the lower-order command received from the command relay device;
With
The command relay device
A command correspondence management table for managing a correspondence relationship between the upper command and the lower command;
When the storage apparatus has reached a specific state in which it is difficult to accept the lower-order commands, the higher-order commands received from the higher-order apparatus based on the command correspondence management table over a predetermined period are collected. An integrated control unit that shifts to a collective throwing mode that can execute a consolidating process that converts to a lower-order command, and issues the lower-order command to the storage device;
An access system comprising:
The storage device
A predetermined number of receiving slots capable of accepting the lower-order command,
The command relay device
2. The access system according to claim 1, wherein, as the specific state, the mode is shifted to the collective throwing mode when there is a vacant space that can accept the lower-order command in the predetermined number of reception slots. .
The command relay device
Monitoring the number of commands issued by the host device per unit time,
2. The specific throwing mode is switched to the collective throwing mode when the number of higher-level commands issued per unit time by the higher-level device exceeds a predetermined threshold as the specific state. The access system described.
The command relay device
As the specific state, triggered by the fact that the number of the lower side commands simultaneously executed in the storage device exceeds a predetermined ratio of the predetermined number of the lower side commands that can be executed simultaneously in the storage device, The access system according to claim 1, wherein the access system shifts to a collective throwing mode.
The command relay device
A management target management table for managing specific high-order commands that can be collectively processed among the group of high-order commands received from the high-order device;
When the higher-order command is received from the higher-level device in the collective throwing mode, the lower-order command is referred to the summarization target management table, and the higher-order command is collected together with other higher-order commands received in the collective throwing mode. The access system according to claim 1, wherein it is determined whether or not a side command can be generated.
The command relay device
Transition from the collective throwing mode to the normal mode is triggered by the fact that the storage device is in a state where it can accept the lower order command and that the collective throwing process has been completed for all the upper side commands. The access system according to claim 1, wherein:
The command relay device
The access system according to claim 1, wherein in the collective throwing mode, the processing order of the higher-order commands received from the higher-order device is switched so that a command to be processed first is processed first.
A higher-level device that issues higher-level commands related to data writing and reading; a command relay device that operates in a normal mode that converts the higher-level commands received from the higher-level device into lower-level commands one-to-one; and the command relay In an access method in an access system comprising: a storage device capable of writing and reading the data according to the lower-order command received from a device;
The command relay device
Based on a command correspondence management table that manages the correspondence between the upper command and the lower command over a predetermined period when the storage device has reached a specific state in which it is difficult to accept the lower command. Integration that shifts to a collective throwing mode in which the high-order commands received from the high-order device can be collectively converted into the low-order commands and that issues the low-order commands to the storage device. An access method characterized by executing a control step.
The storage device
A predetermined number of receiving slots capable of accepting the lower-order command,
The command relay device
9. The access method according to claim 8, wherein, as the specific state, the mode is shifted to the collective throwing mode when the predetermined number of reception slots have a space that can accept the lower-order command. .
The command relay device
Monitoring the number of commands issued by the host device per unit time,
9. The specific state is characterized in that, when the number of higher-order commands issued per unit time by the higher-level device exceeds a predetermined threshold, the batch-throw mode is entered. The access method described.
The command relay device
As the specific state, triggered by the fact that the number of the lower side commands simultaneously executed in the storage device exceeds a predetermined ratio of the predetermined number of the lower side commands that can be executed simultaneously in the storage device, The access method according to claim 8, wherein the access mode is shifted to a collective throw mode.
The command relay device
A management target management table for managing specific high-order commands that can be collectively processed among the group of high-order commands received from the high-order device;
Upon receiving the higher-order command from the higher-level device in the collective throwing mode, the lower-order command is referred to the summary target management table, and the higher-order command is collectively combined with other higher-order commands received in the collective throwing mode. 9. The access method according to claim 8, wherein it is determined whether or not a side command can be generated.
The command relay device
Transition from the collective throwing mode to the normal mode is triggered by the fact that the storage device is in a state where it can accept the lower order command and that the collective throwing process has been completed for all the upper side commands. The access method according to claim 8, characterized in that:
The command relay device
9. The access method according to claim 8, wherein in the collective throwing mode, the processing order of the higher-order commands received from the higher-order device is changed so that a command to be processed first is processed first.