Abstract:
A device manager manages assignments of a plurality of devices by two or more device clients. To this end, the device manager detects an operational failure with a device client running an application based at least partially on an assignment of one or more devices among the plurality of devices. Next, the device manager exclusively resets each assigned device reserved by the device client in response to the detection of the operational failure with the device client while preserving any reservation among the remaining devices.

Description:
FIELD OF INVENTION  
       [0001]     The present invention generally relates to fail-over methods for a high availability environment. The present invention specifically relates to a method for resetting a device assigned to an application server in response to a fail-over state of that application server.  
       BACKGROUND OF THE INVENTION  
       [0002]     In a high availability environment, a fail-over measure is implemented for a fail-over application server to take over operations of a primary application server when the primary application server is experiencing an operational problem. Examples of such an operational problem includes an inability to communicate on the associated network, a system crash, an application crash, and hardware errors that prevent the primary application server from being able to successfully complete operations. When the failover occurs, the fail-over application server launches the applications that were running on the primary application server and takes over the hardware and TCP/IP addresses of the primary application server. When the application is restarted on the fail-over application server, the application is not aware of the fact that it is now running on the fail-over application server. In fact, it would only appear to the application that it was stopped and then restarted.  
         [0003]     One drawback to the implementation of a fail-over measure when the primary application server is experiencing an operational problem can be an inability of the application as restarted by the fail-over application server to use any reserved device previously being used by the application when the operational problem occurred on the primary application server. A challenge therefore for the computer industry is to develop techniques for implementing a fail-over measure when needed while facilitating a use by an application as restarted on the fail-over application server of all devices previously reserved by the application when the operational problem occurred on the primary application server without impacting the performance of any device.  
       SUMMARY OF THE INVENTION  
       [0004]     The present invention provides a new and unique method of managing an assignment of a device to an application server.  
         [0005]     One form of the present invention is a signal bearing medium tangibly embodying a program of machine-readable instructions executable by one or more processor(s) to manage assignments of a plurality of devices among a plurality of device clients. The operations include (1) detecting an operational failure of a device client running an application based at least partially on an assignment to the device client of at least one device among the plurality of devices; and (2) exclusively resetting each device among the at least one device assigned to the device client and reserved by the device client in response to the detection of the operational failure of the device client while preserving any assignment and reservation among the remaining devices by the other device clients.  
         [0006]     A second form of the present invention is system employing one or more processors, and one or more memories for storing instructions operable with the processor(s) for managing assignments of a plurality of devices among a plurality of device clients. The instructions include (1) detecting an operational failure of a device client running an application based at least partially on an assignment to the device client of at least one device among the plurality of devices; and (2) exclusively resetting each device among the at least one device assigned to the device client and reserved by the device client in response to the detection of the operational failure of the device client while preserving any assignment and reservation among the remaining devices by the other device clients.  
         [0007]     A third form of the present invention is server for assignments of a plurality of devices among a plurality of device clients. The server includes (1) means for detecting an operational failure of a device client running an application based at least partially on an assignment to the device client of at least one device among the plurality of devices; and (2) means for exclusively resetting each device among the at least one device assigned to the device client and reserved by the device client in response to the detection of the operational failure of the device client while preserving any assignment and reservation among the remaining devices by the other device clients.  
         [0008]     The forgoing forms and other forms, objects, and aspects as well as features and advantages of the present invention will become further apparent from the following detailed description of the various embodiments of the present invention, read in conjunction with the accompanying drawings. The detailed description and drawings are merely illustrative of the present invention, rather than limiting the scope of the present invention being defined by the appended claims and equivalents thereof.  
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0009]      FIG. 1  illustrates an exemplary operational environment for a device manager and a device client in accordance with the present invention;  
         [0010]      FIG. 2  illustrates flowcharts representative of one embodiment of a device management method in accordance with the present invention;  
         [0011]      FIG. 3  illustrates a flowchart representative of one embodiment of device assignment request management method in accordance with the present invention;  
         [0012]      FIG. 4  illustrates an exemplary device management table in accordance with the present invention;  
         [0013]      FIG. 5  illustrates flowcharts representative of one embodiment of a device client restart method in accordance with the present invention;  
         [0014]      FIG. 6  illustrates an exemplary pre device client fail-over status and a post device client fail-over status of the device management table illustrated in  FIG. 4 ;  
         [0015]      FIG. 7  illustrates flowcharts representative of one embodiment of a device manager polling method in accordance with the present invention;  
         [0016]      FIG. 8  illustrates flowcharts representative of one embodiment of a device manager restart method in accordance with the present invention; and  
         [0017]      FIG. 9  illustrates an exemplary pre device manager restart status and a post device manager restart status of the device management table illustrated in  FIG. 4 .  
     
    
     DESCRIPTION OF THE PREFERRED EMBODIMENT  
       [0018]     Device managers and device clients of the present invention are computer modules structurally configured with hardware, software and/or firmware to implement various conventional applications for a particular computer environment, and to implement a new and unique selective reset of devices within that computer environment in response to any restart of a device manager and in response to any detected operational failure of a device client by a device manager. In practice, the manner by which device managers and device clients of the present invention are structurally configured for practicing the present invention is without limit. Therefore, the description of the following embodiments of a device manager  25  and a device client  26  as incorporated within an exemplary computer environment as illustrated in  FIG. 1  is not a limitation as to the scope of a device manager and a device client of the present invention.  
         [0019]     Referring to  FIG. 1 , a pair of conventional device management servers  20 ( 1 ) and  20 ( 2 ), a X number of application servers  21 ( 1 )- 21 (X), where X≧2, a database  23  and a Y number of devices  24 ( 1 )- 24 (Y), where Y≧2, are interconnected via a conventional network  22 . Device manager  25  is installable on each device management server  20 , and device client  26  is installable on each application server  21  to facilitate an implementation of a device management method of the present invention as represented by flowcharts  30  and  40  illustrated in  FIG. 2 .  
         [0020]     Referring to  FIGS. 1 and 2 , a stage S 32  of flowchart  30  encompasses an execution of initialization routines by each device manager  25  where these initialization routines include conventional initialization routines as would be appreciated by those having ordinary skill in the art, and a new and unique routine for designating one of the device management servers  21  for running its device manager  25  as a primary device manager and the other device management server  21  for initializing its device manager  25  in response to an operational failure of the primary device manager  25 . Similarly, a stage S 42  of flowchart  40  encompasses an execution of initialization routines by each device client  26  ( FIG. 1 ) where these initialization routines include conventional initialization routines as would be appreciated by those having ordinary skill in the art for facilitating a running of an application based, partially or entirely, on assignments of devices  24  to application servers  21 , and a new and unique task for registering which of the device managers  25  installed on device management servers  20  is the primary device manager.  
         [0021]     To facilitate an understanding of the present invention, a stage S 34  of flowchart  30  and a stage S 44  of flowchart  40  will now be described herein as if the device managers  25  installed on device management servers  20  and the device clients  26  installed on application servers  21  concurrently executed stages S 32  and S 42 , respectively, upon an initial operation of the computer environment illustrated in  FIG. 1 . Those having ordinary skill in the art will however appreciate the applicability of flowcharts  30  and  40  to additional device managers  25  and additional device clients  26  subsequently introduced into the computer environment shown in  FIG. 1  and to restarts performed by the existing device managers  25  and existing device clients  26  shown in  FIG. 1 .  
         [0022]     Stages S 34  and S 44  encompass a management by the primary device manager  25  of each conventional device assignment request DAR received from a device client  26 . Generally, a device client  26  will communicate a device assignment request DAR to the primary device manager  25 , which will either accept, deny or queue the device assignment request DAR in dependence as to whether one or more devices among devices  24  responsive to the device assignment request DAR are available. If the device assignment request DAR is accepted by the primary device manager  25  whereby one or more of the devices among devices  24  is assigned by primary device manager  25  to the requesting device client  26 , then the requesting device client  26  can reserve the assigned device(s)  24  to thereby perform one or more tasks via the assigned device(s)  24 . Upon completion of the task(s), the requesting device client  26  releases the reservation of the assigned device(s)  24  and notifies the primary device manager  25  of the reservation release whereby the primary device manager  25  can designate the assigned device(s)  24  as being available for assignment in the device management table  27 .  
         [0023]     In one embodiment of stage S 34 , the primary device manager  25  implements a device assignment request management method of the present invention as represented by a flowchart  50  illustrated in  FIG. 3 . However, in practice, the actual manner by which the primary device manager  25  implements stage S 34  is without limit. Thus, the following description of flowchart  50  is not a limitation as to the scope of stage S 34 .  
         [0024]     Referring to  FIGS. 1 and 3 , the primary device manager  25  creates a device management table (“DMT”)  27  within database  23  during a stage S 52  of flowchart  50 . In one exemplary embodiment, as illustrated in  FIG. 4 , device management table  27  includes a device column listing each device  24  by device name, and an assigned application server column listing which application server among application servers  21  has been assigned the corresponding device  24  in the table.  
         [0025]     Thereafter, the primary device manager  25  will manage device management table  27  during a stage S 54  of flowchart  50  based on (1) conventional device assignment requests DAR received from device clients  21 , and (2) any detection by the primary device manager  25  of an operational failure by one of the device clients  21 . In practice, the manner in which the primary device manager  25  detects an occurrence of an operational failure of one of the device clients  21  is without limit. Thus, the following description of  FIGS. 5-7  is not a limitation as to the scope of stage S 54 .  
         [0026]     Referring to  FIGS. 1 and 5 , a flowchart  60  and a flowchart  70  are implemented by the primary device manager  25  and a failover device client  26 , respectively, upon a restart of the failed device client  26  on a fail-over application server  21  by the failover device client  26  in accordance with flowchart  40  ( FIG. 2 ). Specifically, the operational failure of the failed device client  26  triggers an establishment of an initialization path IP 1  between the primary device manager  25  and the failover device client  26  during a stage S 62  of flowchart  60  and a stage S 72  of flowchart  70 . The primary device manager  25  interprets initialization path IP 1  as an indication of the operational failure of the failed device client  26  whereby, during a stage S 64  of flowchart  60 , the primary device manager  25  selectively resets each device  24  assigned to the failed device client  26  that was also reserved by the failed device client  26  prior to the restart by the failover device client  26  and updates device management table  27  to reflect that each reset device  24  is now available for assignment. For example, as illustrated in  FIG. 6 , if the failed device client  26  was running on application server  21 ( 3 ) and device  24 ( 5 ) was assigned to application server  21 ( 3 ) prior to the restart, then the primary device manager  25  would conventionally release assigned device  24 ( 5 ) from the reservation previously established by the failed device client  26 .  
         [0027]     In practice, the manner by which the primary device manager  25  resets each device  24  reserved by the failed device client  26  is without limit. In one embodiment, the primary device manager  25  queries an AIX ODM database for a logical unit number (“LUN”) of each device  24  reserved by the failed device client  26  prior to the restart whereby the primary device manager utilizes the LUN to reset the device(s)  24 .  
         [0028]     A stage S 74  of flowchart  70  encompasses the failed device client  26  to execute any additional initialization tasks related to the primary device manager  25 .  
         [0029]     Those having ordinary skill in the art will appreciate that, upon the termination of flowcharts  60  and  70 , the released device  24  will now be available for assignment to one of the device client  26  as will be reflected in device management table  27 , and any reservation among the remaining assigned devices  24  was preserved.  
         [0030]     Referring to  FIGS. 1 and 7 , a flowchart  80  and a flowchart  90  can be implemented in accordance with a schedule by the primary device manager  25  and each device client  26 , respectively, during stage S 54  ( FIG. 3 ) to enable the primary device manager  25  to actively ascertain operational failures by the device clients  26 . Specifically, during a stage S 82  of flowchart  80 , the primary device manager  25  will poll a device client  26  via a poll message P 1  that may or may not be received by the device client  26 . If poll message P 1  is received by the device client  26  during a stage S 92  of flowchart  90  as indicated by the solid arrow, then the device client  26  will proceed to a stage S 94  of flowchart  90  to respond to the poll message P 1  via a reply message R 1 . If reply message R 1  is timely received by the primary device manager  25  during a stage S 84  of flowchart  80  as indicated by the solid arrow, then the primary device manager  25  will terminate flowchart  80 . Otherwise, if reply message R 1  is not timely received by the primary device manager  25  during stage S 84  as indicated by the dashed arrow, then the primary device manager  25  interprets the failure to timely receive the reply message R 1  as an operational failure of the device client  26  whereby the primary device manager  25  selectively reset each device  24  assigned to the failed device client  26  that was reserved by the failed device client  26  during a stage S 86  of flowchart  80 .  
         [0031]     Those having ordinary skill in the art will appreciate that, upon the termination of flowcharts  80  and  90 , the released device  24  will now be available for assignment to each active device client  26 , and all reservations among the remaining assigned devices  24  were preserved.  
         [0032]     Referring to  FIGS. 1 and 3 , from the description herein of  FIGS. 5-7 , those having ordinary skill in the art will appreciate the numerous advantages of flowchart  50 . In particular, the selective reset by the primary device manager  25  of reserved devices  24  under detected operational states of device clients  26 . Those having ordinary skill in the art will further appreciate the fact that the primary device manager  25  may fail, and therefore be restarted on a new device management server  20  by its device manager  25 .  FIG. 9  illustrates flowcharts  120  and  130  as representations of a device manager restart method of the present invention.  
         [0033]     Referring to  FIGS. 1 and 8 , flowcharts  100  and  110  are implemented by the failover device manager  25  and each device client  26 , respectively, upon a restart by the failover device manager  25  on a new device management server  20  in accordance with flowchart  30  ( FIG. 2 ). Specifically, the failover device manager  25  triggers an establishment of an initialization path IP 2  between the failover device manager  25  and a device client  26  during a stage S 102  of flowchart  100  and a stage S 112  of flowchart  110 . The failover device manager  25  thereafter proceeds to a stage S 104  of flowchart  100  to request an update of all devices  24  assigned to each device client  26  via an assignment device update request message ADUR. The device client  26  will process the message ADUR during a stage S 114  of flowchart  110  whereby the failover device manager  25  will update the device management table  27  by selectively resetting each assigned device  24  reserved by the device client  26  and designating these device(s)  24  as being available for assignment if the device client  26  fails to timely response to the message ADUR, or by designating an assigned device  24  to a device client  26  as being available for assignment if the device client  26  indicates the assigned device  24  has been released by the device client  26 . For example, as illustrated in  FIG. 9 , if the device client  26  running on application server  21 ( 4 ) did not timely response to the message ADUR, then the failover device manager  25  would conventionally release device  21 ( 4 ) if it was reserved by the device client and update device management table  27  to reflect device  21 ( 4 ) is available for assignment. Or, if the device client  26  indicates that device  24 ( 1 ) has been released by device client  26 , then the failover device manager  25  would just update device management table  27  to reflect device  21 ( 4 ) is available for assignment.  
         [0034]     Those having ordinary skill in the art will appreciate that, upon the termination of flowcharts  100  and  110 , the released device  24  will now be available for assignment to any of the device clients  26 , and all reservations among the remaining devices  24  were preserved.  
         [0035]     Referring again to  FIG. 1 , in a practical embodiment, device manager  25  and device client  26  are embodied as a software module written in a conventional language integrated with a commercially available software application entitled “IBM Tivoli Storage Manager”. As such, device manager  25  and device client  26  are installed within a memory of a server or distributed among various server memories whereby the server processor(s) can execute device manager  25  and device client  26  to perform various operations of the present invention as described in connection with the illustrations of  FIGS. 2-9 .  
         [0036]     While the embodiments of the present invention disclosed herein are presently considered to be preferred embodiments, various changes and modifications can be made without departing from the spirit and scope of the present invention. The scope of the invention is indicated in the appended claims, and all changes that come within the meaning and range of equivalents are intended to be embraced therein.