Method, apparatus and program storage device for providing data path optimization

The present invention is a method, apparatus and program storage device for providing data path optimization for redundant data paths. The present invention provides data path optimization that increases the data access throughput and availability to a device by using multiple paths when a modification event occurs.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a computer system. More particularly, the present invention relates to a method, apparatus and program storage device for providing data path optimization for redundant data paths.

2. Description of Related Art

In recent years, installed disk storage capacity has seen an almost exponential growth at customer sites. This exponential growth has been coupled with the movement away from direct attached storage to networked storage, be it either storage area network (SAN) or network-attached storage (NAS). Also, the movement has resulted in an ever-increasing complexity of the storage management environment.

Implementing a successful application to resolve the complexity of the storage environment is as much an art as it is a science. Companies are increasingly struggling with applications that require extraordinary resources. In some cases, these resources require expensive components plus increased fees for software licensing.

Storage designers and application developers need to address multiple concerns when developing storage solutions. A few of those concerns include multiple data paths, failover, transaction and batch elapsed time, the amount of CPU required to sustain transaction and batch processes, and concurrency. These metrics quantify a storage network and its database's performance. To ensure good performance, designers and developers should incorporate an understanding of the importance of each of these metrics into all of their applications.

Multiple, or redundant, data paths between, for example, a server and a storage subsystem is extremely important for optimum system performance and availability of the storage subsystem. If a failure occurs in the data path between a system server and a remote data storage subsystem, automatic switching of the input/output (I/O) to another path is essential for performance and availability of the system overall.

To improve the performance and availability of data access, from a host to remote data storage subsystems for example, the host machine must be able to access remote data storage subsystems through multiple paths thereby increasing the data access throughput and improve availability, and providing failover protection. A database optimizer works to find the best access path to access data through the multiple paths. The optimizer will figure out the shortest path to the data and determine the least expensive way to complete the work even in the event of a single or multiple path failure. In addition, an I/O workload can be spread over multiple active paths by the optimizer, which can eliminate bottlenecks that occur when many I/O operations are directed to a device, such as a common disk device, across the same path.

An optimizer may also help to reduce I/O transmission time. When tables and indexes to physical devices are designed properly, programs can update a database with information that enables the optimizer to take the minimum path. Finding the best path helps reduce I/O and CPU expenditure and fulfills application requests for data as quickly and as efficiently as possible.

However, in host-to-remote data storage subsystems, an operating system (OS) sees separate bus paths to the same device and the OS is unaware that the separate bus paths are in fact connected to the same device. For example, multiple bus paths may be connected to the same storage subsystem. Hence, when a path fails, a “Write Delay Error” would be generated for that path instead of failing over to another path.

Moreover, current optimization products do not support access to remote devices, such as remote data storage subsystems, through multiple paths on all platforms. For example, one product's algorithm for remote storage through multiple paths may work well on a UNIX™ platform, but not be compatible with an operating system using Plug and Play, such as on a Windows™ platform. On these platforms, which are not fully Plug and Play compatible, write errors are encountered.

It can be seen that there is a need to provide data path optimization for redundant data paths to allow access to devices through multiple paths on multiple platforms.

It can also be seen that there is a need for data path optimization that supports multi-path device operation with Plug and Play compatibility.

SUMMARY OF THE INVENTION

To overcome the limitations in the prior art described above, and to overcome other limitations that will become apparent upon reading and understanding the present specification, the present invention discloses a method, apparatus and program storage device for providing data path optimization for redundant data paths.

The present invention solves the above-described problems by utilizing a virtual device controller providing data path optimization for redundant data paths to increase the data access throughput and availability to a device by using multiple paths. The virtual device controller, which provides data path optimization, is fully compatible with a Plug and Play environment.

A virtual device controller for multi-path operation in accordance with the principles of the present invention includes a first driver for detecting a modification event on a data path, and a second driver, coupled to the first driver, for creating a redundant data path for the data path, wherein the first driver communicates the modification event to the second driver, the second driver creating the redundant data path in response to the modification event.

In another embodiment of the present invention, a cluster environment for multi-path operation is provided. The cluster environment includes a memory and a plurality of hosts, wherein each host includes a virtual device controller that includes a first driver for detecting a modification event on a data path and a second driver, coupled to the first driver, for creating a redundant data path for the data path, wherein the first driver communicates the modification event to the second driver, the second driver creating the redundant data path in response to the modification event.

In another embodiment of the present invention, a program storage device is provided. The program storage device tangibly embodies one or more programs of instructions executable by the computer to perform a method for providing multi-path operation, wherein the method includes detecting a modification event on a data path and creating a redundant data path for the data path in response to the modification event.

In another embodiment of the present invention, a method for providing multi-path operation is provided. The method includes detecting a modification event on a data path and creating a redundant data path for the data path in response to the modification event.

In another embodiment of the present invention, another virtual device controller for multi-path operation is provided. This virtual device controller includes a first means for detecting a modification event on a data path and a second means, coupled to the first means, for creating a redundant data path for the data path, wherein the first means communicates the modification event to the second means, the second means creating the redundant data path in response to the modification event.

DETAILED DESCRIPTION OF THE INVENTION

The present invention provides a method, apparatus and program storage device for providing data path optimization for redundant data paths. The present invention utilizes a virtual device controller to provide data path optimization for redundant data paths to increase the data access throughput and availability to a device by using multiple paths.

FIG. 1illustrates a storage subsystem100for multiple platforms. A storage system100allows the consolidation of data from different platforms on a single high performance, high availability storage server150. Host servers110–140may each use different types of connections180–186to connect to the storage server150, e.g., fibre channel, copper, wireless, etc. However, the present invention is not limited to these connections.

The storage system100supports many diverse platforms. For example, the storage system may support IBM, UNIX, WINDOWS and NOVELL host servers110–140. However, the present invention is not limited to supporting only these servers. The storage server150may include, but is not limited to, disk, tape and optical storage media, processors, and software. Virtually all types of servers110–140can concurrently attach to the storage server150. As a result, the storage server150can be an external disk storage system as well as a storage system in heterogeneous storage area network (SAN) environments operated by a storage manager160via a network170.

The different servers110–140may also use different connection protocols. For example, the storage server150is equipped to handle either small computer system interface (SCSI) connectivity, INTEL-based servers or enterprise systems connection (ESCON) technology. However, the present invention is not limited to these technologies.

FIGS. 2aand2billustrate an interface to a remote device in a multi-path configuration200a,200baccording to the present invention. Multiple host adapters220,230such as SCSI connections can provide a host210with internal redundancy. These multiple adapters220,230can provide paths for data flow during input and output operations of the host210. One goal of this configuration would be to create path redundancy and the ability to switch between these adapters220,230, providing multiple paths240,250for the data to travel. Hence, in the event of a failure, I/O operations from a failed path would be automatically rerouted to a remaining path (i.e., failover), optimizing the I/O data paths.

A method for optimizing data path selection is implemented by the host server210and be used to create redundant connections240,250between the host server210and a device, such as a disk storage subsystem260–270. The redundant connections240,250can provide data path redundancy and possibly the ability to switch between these devices260,270providing many different paths for the data to travel, enhancing data path performance and availability. Multi-paths240,250could then provide load balancing of data flow and prevent a single path from becoming overloaded, causing input-output (I/O) congestion that occurs when many I/O operations are directed to common devices along the same I/O path.

InFIG. 2a, it would be advantageous for a device280, such as a storage subsystem, to be configured so that the device280would appear as two devices260,270on more than one adapter220,230, respectively, for the single host210. This would eliminates a single host adapter, for example adapter1220, as a single point of failure, thus increasing availability of data through multiple redundant data paths240,250and also could improve system performance by balancing the subsystem's I/O workload across the multiple paths240,250.

Unfortunately, open system operating systems do not recognize or support such a configuration. InFIG. 2a, the host's operating system detects separate bus paths240,250to a device280as separate devices, i.e. device1260and device2270. The operating system is not aware they the devices260,270are in fact the same device280. For example, in WINDOWS W2K, the paths to a single device280will appear as separate disk numbers, device1260and device2270, when viewed by a computer management graphics user interface (GUI).

FIG. 2billustrates an actual configuration200bof a host interface according to the present invention. The devices260,270, as shown inFIG. 2a, are in fact the same device280. The connections240,250are actually multiple paths to the same device280. Accordingly, in order to create multi-path configurability, it is necessary to add a virtual device controller with an additional device driver layer to the device I/O driver architecture. This additional device driver layer will recognize devices with multiple access paths240,250and treat them as connecting to a single device280.

FIG. 3illustrates a protocol stack300without a virtual device controller according to the present invention. InFIG. 3, a device driver310forms an interface between an operating system305and a device330. The device driver310communicates with an adapter driver320. The adapter driver320is connected via an internal cable to the device330. The adapter driver320is capable of controlling one or more devices330connected to the adapter driver320.

FIG. 4illustrates a protocol stack400having a virtual device controller with Plug and Play (PnP) capabilities according to the present invention. A Plug and Play environment is a combination of hardware and software support that enables a computer system to recognize and adapt to hardware configuration changes with little or no user intervention. For example, a user can dock a portable computer and use the docking station's Ethernet card to connect to the network without changing the configuration. Later, the user can undock that same computer and use a modem to connect to the network, again without making any manual configuration changes.

The protocol stack400having the virtual device controller480is designed and implemented to exploit, at least, the multi-path configurability that a host-to-device, such as a host interface to a storage subsystem, may offer. The virtual device controller480consists of at least three different drives: a virtual bus driver (bus driver)420, a virtual function driver (function driver)430, and a virtual mini-port filter driver (mini-port filter driver)440. However, the present invention is not limited to these drivers, and addition drivers may be implemented.

The virtual bus driver420and virtual function driver430are located between the device driver410and the adapter450. However, the present invention is not limited to these driver locations. When loaded, the virtual function driver430may registers itself to the virtual bus driver420. The virtual function driver430(or function driver) may be used as a substitute for the MICROSOFT disk class driver, handling all Plug and Play issues.

However, in one embodiment, the virtual function driver430doesn't provide any device functions, such as disk functions. Accordingly, a volume manager, which may be located in the operating system405, and other storage components located above the function driver430in the protocol stack400cannot mount and use, for example, the disk devices driven by this virtual function driver430. Hence, all paths to a physical device460, such as a storage subsystem (disk), are hidden. However, the present invention is not limited to this embodiment and alternate embodiments may be implemented providing the virtual function driver430with additional device functionality.

The virtual bus driver420, which may be loaded at boot time, creates a virtual device and a new data path, i.e., it identifies devices on its bus and create device objects for them. However, the present invention is not limited to this loading time. For example, the virtual bus driver420will create a virtual disk device for every physical disk connected to a host and exposes this physical disk device to the OS405. Accordingly, the virtual bus driver420can handle multi-path access to physical devices460. Also, the virtual bus driver420controls all Plug and Play aspects of the virtual devices that it creates.

The virtual mini-port filter driver440can modify the behavior of device hardware or add additional security features. The virtual mini-port filter driver440may be loaded at boot time. However, the present invention is not limited to this loading time.

The virtual mini-port filter driver440can be used to scan a list of devices stored in a memory location. The virtual mini-port filter driver440will remove any of the devices in the list that the virtual mini-port filter driver440is directed to by an operator, software command, operating system etc. However, the virtual mini-port filter440of the present invention is not limited to these directions. A virtual mini-port filter driver440is optional and can exist in any quantity, placed above or below the virtual function driver430and above the virtual bus driver420.

FIG. 5illustrates an architecture500having a virtual device controller according to the present invention. An I/O system provides a layered architecture for drivers. In general, a driver creates device objects for each device it controls; the device objects represent the device to a device driver. From the Plug and Play perspective, there are at least three kinds of device objects. As presently defined, these device objects include physical device objects (PDOs), functional device objects (FDOs), and filter device objects.

According to the present invention, PDOs575,580represent devices510,515, respectively, connected to a bus599. Every Plug and Play application program interface (API) that refers to the devices510,515refers to the PDOs575,580. For example, an API referring to device1510may refer to PDO575and an API referring to device2510may refer to PDO580.

FDOs represent the functionality of a device518to a function driver537. For example, the FDOs550,555represent the functionality of the device1510to the function driver537. FDOs are used to, but are not limited to, servicing device PDOs by passing I/O requests down to the adapter ports527. For example, device FDOs590,595may service PDOs575,580for a device driver585.

The FDOs550,555,560,565are loaded, for example, when adapters520,525detect a modification event such as a device518connected to an I/O path511,516during a Plug and Play event. A modification event is any event that requires a modification or configuration to a system such that the system requires a mapping or remapping of the systems data paths.

When an FDO is loaded due to a modification event, such as a Plug and Play event for example, the function driver537reports the modification event to a bus driver570. In this way, a connection567between the function driver537and the bus driver570is created. The bus driver570then may register this FDO550,555,560,565to a PDO530,535,540,545, respectively.

To register an FDO550,555,560,565to a PDO530,535,540,545, the bus driver570may first search a memory location592including a PDO list to see if a new PDO530,535,540,545should be created. If a new PDO needs to be created, the bus driver570will create a new PDO530,535,540,545and register the FDO550,555,560,565to the new PDO530,535,540,545, else, the FDO550,555,560,565is registered to an existing PDO530,535,540,545found in the list. Also, along with the creation of the PDO530,535,540,545a new path576,581,577,582is created, respectively.

When a path576,581,577,582is removed, the function driver537reports this modification event to the bus driver570, whereby the bus driver570will remove the corresponding FDO550,555,560,565. The bus driver570will also search the PDO list to see if the PDO530,535,540,545should be removed.

An open system operating system creates separate bus paths576,582to a device518and treats the device518as separate devices510,515(i.e., I/O597to device1510via path576and I/O598to device2515via path582). Accordingly, the operating system is not aware that the separate devices510,515are in fact the same device518. For example, in WINDOWS W2K, the paths511,516to a single device518will appear as paths to separate devices510,515having different disk numbers (e.g., device1510and device2515) when viewed by a computer management graphics user interface (GUI). If a failure occurs on a path576,582, no failover to another path577,581will occur.

In operation, when the device518is connected to the architecture500(i.e., a modification event), the adapters520,525detect the presence of the device518and report the device518to the operating system (OS). The OS sees the device518as two separate devices having two separate paths576,582as discussed above. Hence, according to the present invention, a virtual device controller578is utilized to provide redundancy and availability to the device518by creating additional paths577,581to device518. The virtual device controller578accomplished this by additional device drivers in the architecture of the protocol stack400as shown inFIG. 4and the architecture500ofFIG. 5.

Before any I/O communication occurs, a determination is made as to if a modification event, such as Plug and Play event, has occurred. A modification event may occur when a device is added or removed to the bus599as detected by adapters520,525. However, one skilled in the art will realize that numerous other modification events exist. When a modification event, such as a Plug and Play event, on a path occurs, the function driver537handles the event then signals the bus driver570. Using this event, bus driver570can change an I/O path state, e.g., from one path576to another577.

In the architecture500according to the present invention, configuration of the virtual device controller578occurs when a modification event, such as a newly added device518is detected on the adapters520,525. The function driver537signals the bus driver, and the bus driver determine if a PDO530,535,540,545should be created or not, if a PDO should be removed, or if a path should be added or removed, or the state of a path should be updated for the newly detected device518.

More specifically, when the bus driver570is signaled, the bus driver570creates a new underlying FDO550,535,560,565, then searches a PDO list to find a PDO530,535,540,545to register the FDO550,535,560,565to. If no PDO is found, the bus driver570create a new PDO530,535,540545, then register FDO550,535,560,565to this new PDO, respectively, and informs a modification event manager, such as a Plug and Play manager, to enumerate it. If a PDO already exists, the new FDO550,535,560,565is registered to the existing PDO. Hence, the bus driver570creates new and redundant paths576,577,581,582to the device518. The redundant paths576,577,581,582also providing load balancing and greater device availability.

FIG. 6is a flow diagram600illustrating the configuration of the virtual device controller. Before any I/O communication occurs, a determination is made as to if a modification event has occurred. The function driver determines if a modification event has occurred610. If a modification event has occurred612, the function driver notifies the bus driver as to the event620. If a modification event does not occurred614, the function driver will continue to monitor for a modification event.

Accordingly, when the individual adapters detect a modification event, such as a Plug and Play event, the adapters report the device to the operating system (OS). However, due to the separate adapters, the OS sees the single device as two separate devices. The bus driver then determines if a PDO should be created, if a PDO should be removed, if a path should be added or removed, or the state of a path should be updated630. The present invention is not limited to these actions by the bus driver.

In this manner, according to the present invention, a virtual controller creates redundant paths to the connected device. Further, the virtual controller provides high availability to the device and I/O load balancing via additional paths. Hence, when there is a path component failure, I/O will be intelligently rerouted through another adapter connected to the same device.

FIG. 7is a flow diagram700illustrating I/O operation of the virtual device controller according to the present invention. A system determines whether the bus driver receives an I/O request710. If a bus driver receives an I/O request712, it selects an optimum data path from a search the memory location (FIG. 5,592) including a list of available paths using a data path optimization method720. The system waits otherwise714. Then the bus driver sends this I/O request to the function driver730via the selected optimum data path. The function driver sends the request received from the bus driver via the optimum data path to the adapter driver740. An adapter receives the request from the adapter driver and transmits the request this request to a physical device750.

According to the present invention, the PDOs created by bus driver are also devices. When an I/O request for a specific PDO is received, the bus driver routes this I/O request to a specific path that corresponds to a specific FDO serviced by the function driver, and on to the specified PDO.

FIG. 8illustrates a cluster environment800with Plug and Play compatibility according to the present invention. Host servers may be configured with multiple host adapters and/or SCSI connections850–880to a storage server890.FIG. 8shows that hosts810–840may be attached through a SCSI, fibre-channel or other type of interface850–880to other hosts810–840or a storage server890, hence, providing component redundancy and a multi-path configuration. In the cluster environment800, clusters having multiple host interfaces850–880provide more flexibility in the number of I/O paths that are available. When there is a failure, the data path may be optimized by rerouting I/O operations from the failed path to any remaining paths.

FIG. 9illustrates a virtual controller system900that provides data path optimization according to the invention as illustrated with reference toFIGS. 1–8using an executable program readable from a storage driver program. The process illustrated with reference to the present invention may be tangibly embodied in a computer-readable medium or carrier, e.g. one or more of the fixed and/or removable data storage devices968illustrated inFIG. 9, or other data storage or data communications devices. A computer program990expressing the processes embodied on the removable data storage devices968may be loaded into the memory992or into the system900, e.g., in a processor996, to configure the system900ofFIG. 9, for execution. The computer program990comprise instructions which, when read and executed by the controller900ofFIG. 9, causes the system900to perform the steps necessary to execute the steps or elements of the present invention.