In many computer systems using external data storage subsystems, there are multiple physical paths, or buses, to each data storage subsystem. One reason for having multiple paths is to provide redundancy in the case of a failed path. The selection of a path for sending an I/O request can affect the quality of service for applications initiating I/O requests because paths have limited capacity for carrying data. Path capacity limitations may be the result of multiple influences, such as the fundamental bandwidth limitation of the physical connection or the storage subsystem's front-end resources for processing requests. An I/O request that cannot be sent immediately due to path capacity limitations may be queued on the host, and the response time for a queued I/O request may increase accordingly.
One known path allocation strategy is the allocation of all available paths for the transmission of any I/O requests and their associated responses. This strategy maximizes the use of the capacity of the available paths. However, some I/O requests may be more sensitive to response time and such a path allocation strategy may result in slower response times than desirable for those I/O requests. An I/O request may be sensitive to response time, and a user may designate such a request as “high priority”, for various reasons including the importance of the application initiating the I/O request or due to the type of I/O used by the application (i.e. synchronized I/O requests may be higher priority than unsynchronized I/O requests).
To accommodate high priority I/O requests, some prior art computer systems allocate at least one path for the transmission of high priority I/O requests to a data storage subsystem and responses thereto. In these systems, other paths are allocated for the transmission of the remaining data traffic. In a database application, for example, redo log write requests may be designated as high priority I/O requests in comparison with data write requests, and a path to the data storage subsystem may be allocated for the transmission of redo log write requests and responses thereto. If redo log write requests do not have a dedicated path to the data storage system, the response time for those requests may be longer than desirable.
Slow responses to redo log write requests transmitted via general purpose paths may be especially evident in database applications where data write requests are aggregated on the host and then sent to the data storage subsystem in a burst. When a burst of I/O is sent, the response time for a redo log request can suffer due to the volume of data write I/O requests being sent on the general purpose paths which have limited capacity.
Another known path allocation strategy is the allocation of one or more paths for I/O requests directed to one or more particular logical units (LUNs) where the response times for such requests are important. Nonetheless, in some systems there is a limited number of paths and assigning a dedicated path may not be possible. Even in systems that have many paths, dedicating one or more paths for the transmission of high priority requests may lead to a higher response time than desirable for lower priority requests. One reason for higher response times for lower priority requests is that the system cannot use the transmission capacity of the dedicated paths even when there are no high priority requests to be sent from the host.
Other prior art strategies, such as Network QoS control programs, run on network switches or routers such as CISCO routers and allow portions of paths to be dedicated for each application. However, Network QoS control programs do not take into account the limitations of the storage-subsystem for handling I/O requests and the capacity is statically allocated for each application without regard to the actual open I/O requests.
USPTO Backgrounds
USPTO Backgrounds