Estimator program for estimating the availability of an application program that runs in a cluster of at least two computers6334196Abstract An estimator program is disclosed which performs method steps for estimating the availability of an application program that runs on any computer in a cluster of at least two computers. By the availability of an application program is herein meant the probability that at any particular time instant, at least one of the computers in the cluster will actually be servicing requests from external workstations to use the application program. In one embodiment, the estimator program begins by receiving input parameters which include 1) multiple downtime periods for each computer in the cluster that occur at respective frequencies due to various downtime sources, and 2) an application failover time period for switching the running of the application program from any one computer to another. From those input parameters, the estimator program estimates first and second annual stoppage times, and then determines the availability of the application program on the cluster from the sum of the first and second annual stoppage times. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
TABLE I
COMPONENT DESCRIPTION
10 Component 10 is a complete digital computer
which is capable of storing and executing
various software programs by itself. All of
the items which are included within computer 10
are represented in FIG. 1 as hardware 10a and
as software 10b. For example, the hardware 10a
will include an instruction processor (such as
an Intel 486), a random access semiconductor
memory, and a magnetic disc memory. Also as an
example, the software 10b will include an
operating system (such as the Windows NT Server
Operating System from Microsoft Corp.), and
several application programs.
20 Component 20 is substantially similar in all
respects to component 10 and it can be a
duplication of the component 10. Thus,
component 20 is a complete digital computer
which is capable of storing and executing the
same software programs as those which are
stored and executed by computer 10.
30 Component 30 is substantially similar in all
respects to component 10 can it can be a
private communications channel between two I/O
ports on the computers 10 and 20. On this
channel, the computers 10 and 20 can send
messages and data to each other.
40 Component 40 is an external magnetic storage
device, such as an array of discs, which is
coupled to both of the computers 10 and 20.
This storage device 40 provides a database, and
all information that is stored on the magnetic
storage device 40 can be accessed by the
computers 10 and 20.
50 Component 50 is a control terminal which is
coupled to both of the computers 10 and 20.
This control terminal 50 is used by a system
administrator to oversee the operation of the
computers 10 and 20. For example, the system
administrator uses the control terminal 50 to
selectively stop the computers 10 and 20 for
maintenance. Also the system administrator
uses the control terminal 50 to direct the
loading of new software programs and software
upgrades into the computers 10 and 20.
60 Component 60 is a single cluster which consists
of all of the components 10-50.
70 Component 70 is a communications network which
is coupled to I/O ports on the computers 10 and
20. On this communications network 70, messages
can be sent to the computers 10 and 20 from an
external workstation. This network 70 can be
the Internet, for example.
80 Each component 80 is a workstation which is
coupled to the cluster 60 via the
communications network 70. At each workstation
80, an operator 80a can use an I/O device (such
as a keyboard or a mouse) to request that
various operations be performed by an
application program in the cluster 80.
To initiate the use of one of the application programs in the FIG. 1 system, an operator 80a at a workstation 80 makes an input via his keyboard or mouse. For example, the operator 80a can use his mouse to select a particular item that is displayed on his monitor, and that selection can implicitly ask for certain information that is provided by a particular application program. In response to such an input by the operator 80a, the workstation 80 sends a request via the communication network 70 to the cluster 60. From the point of view of the operator 80a, the cluster 60 is a single indivisible node. Thus, computer 10 can respond to the request by running the particular application program and sending a result back to the workstation 80; or, computer 20 can respond to the request in the same fashion. Initially, in the cluster 60, all requests on the network 70 to use the application programs are handled by the computer 10. This mode of operation continues until computer 10 becomes unavailable. Then, all requests on the network 70 to use an application program are handled by computer 20. Once computer 20 starts to handle all requests on the network 70 for use of the application programs, that mode of operation continues until computer 20 becomes unavailable. Then, if computer 10 is available, all requests on the network 70 to use the application programs are handled by computer 10. At various times, computer 10 and computer 20 will both be unavailable; and when that occurs, all requests on the network 70 to use an application program will fail. Thereafter, if computer 10 becomes available before computer 20, then computer 10 will handle all requests on the network 70 to use the application programs. Conversely, if computer 20 becomes available before computer 10, then computer 20 will handle all requests on the network 70 to use the application programs. Each of the computers 10 and 20 can become unavailable at any time for three different reasons; and this is illustrated in FIG. 2. There, a curve 101 shows the stoppage of either one of the computers 10 or 20 due to an error in the software 10b or 20b. Also in FIG. 2, a curve 102 shows the stoppage of either one of the computers 10 or 20 due to a fault in the hardware 10a or 20a. Further in FIG. 2, a curve 103 shows the stoppage of either one of the computers 10 or 20 due to human errors by the system administrator 50a. Inspection of the curves 101, 102 and 103 show that the software caused stoppages, the hardware caused stoppages, and the system administrator caused stoppages each occur in a random manner with different time durations and different frequencies. For example, in curve 101, two software caused stoppages occur with time durations Tb1 and Tb2; and they are spaced by time intervals Ta1, Ta2 and Ta3. In curve 102, one hardware caused stoppage occurs with a time duration Td1; and it is spaced by time intervals Tc1 and Tc2. In curve 103, three system administrator caused stoppages occur with time durations Tf1, Tf2 and Tf3; and they are spaced by time intervals Te1, Te2, Te3 and Te4. Hardware stoppages are caused by the failure of a physical structure within the computers 10 and 20. These physical structures include various items such as power supplies, circuits within the instruction processor, circuits within the random access semiconductor memory, etc. As a realistic average, one hardware stoppage occurs every 1,000-20,000 hours with a time duration for repair of 1-60 hours. Software stoppages are caused for a faults within the operating system and/or the application programs 10b and 20b. High quality certified software has a small number of faults, whereas low quality uncertified software has a large number of faults. As a realistic average, one software stoppage occurs every 1-1,000 hours with a time duration of 1-60 minutes. System administrator stoppages are caused by both intentional and unintentional acts of the system administrator 50a. For example, an intentional stoppage occurs when the system administrator stops one of the computers 10 and 20 to perform maintenance on it or to upgrade the software. An unintentional stoppage occurs when the system administrators makes any error which causes one of the computers 10 or 20 to malfunction. For example, the system administrator 50a can inadvertently delete a file from computer 10 which is needed by the application programs. As a realistic average, one system administrator stoppage occurs every 1-500 hours with a time duration of 1-30 minutes. Turning now to FIG. 3, it shows an example of how the hardware stoppages, software stoppages, and system administrator stoppages affect the availability of an application program in the cluster 60. Included in FIG. 3 are seven curves 111-117. Curves 111, 112, and 113 show the operation of computer 10; curves 114, 115 and 116 show the operation of computer 20; and curve 117 shows the downtime for the cluster 60 as a whole. During the cluster downtime of curve 117, the application programs are not available for use by the workstations 80. Initially in FIG. 3, at time T0, both of the computers 10 and 20 are operable as is shown by curves 112 and 115. Also at time T0, all requests on the network 70 to use the application programs are handled by computer 10, and this is shown by curves 111 and 114. Thereafter, at time T1, a hardware stoppage occurs in computer 10. Due to that hardware stoppage, computer 20 enters a failover mode of operation wherein the responsibility of handling requests on the network 70 to use the application programs is transferred to computer 20. In FIG. 3, the reconfigure mode of operation lasts for one minute; and this is shown by curve 116. During that time interval, none of the application programs on the cluster 60 are available for use by the workstations 80, and this is shown by curve 117. Thereafter, at time T2, computer 20 begins to service the requests from the workstations 80 to use the application programs. This is shown by curve 114. That mode of operation continues until the operation of computer 20 ends due to a hardware stoppage, a software stoppage, or a system administrator stoppage. Meanwhile, corrective action is taken by the system administrator to fix the hardware problem in computer 10. In FIG. 3, this corrective action takes place during a six hour time period which starts at time T1 and ends at time T3. Next, at time T4 in FIG. 3, a software stoppage occurs in computer 20. Thus, computer 20 becomes inoperable as shown by curve 115; and computer 10 enters the failover mode of operation as shown by curve 113. In that failover mode, the responsibility for handling all requests on the network 70 to use the application programs is transferred to computer 10. This reconfiguration mode of operation last for one minute. Then as shown by curve 111 at time T5, computer 10 begins handling all of the requests which occur on the network 70 to use the application program. That mode of operation continues until computer 10 becomes inoperable due to a hardware stoppage, a software stoppage, or a system administrator stoppage. Meanwhile, the system administrator takes corrective action on computer 20 to fix the software stoppage that started at time T4. In FIG. 6, this corrective action is completed in a time interval of one hour, which ends at time T6. Thereafter, computer 10 becomes inoperable due to a system administrator stoppage; and this is shown at time T7 in curve 112. In response, computer 20 enters the failover mode of operation wherein it becomes responsible for handling all requests on the network 70 to use the application programs. This failover mode of operation lasts for one minute; and then, at time T8, the servicing the requests by computer 20 begins. Meanwhile, the system administrator 50a acts to correct the system administration stoppage problem. This corrective action is completed in a half-hour time period which ends at time T9. Turning next of FIG. 4, the availability of an application program in the cluster 60 is indicated by a state diagram. Initially, the cluster 60 operates in a state S1 wherein both of the computers 10 and 20 are available to run the application programs. But in state S1, only one of the computers 10 or 20 is servicing requests from the workstations 80 to use to application program, while the other computer is idle. Cluster 60 remains in state S1 until a hardware stop or a software stop or a system administrator stop occurs in the computer which is servicing the workstation requests. When a hardware stop occurs, a transition is made from state S1 to state S2A; when a software stop occurs, a transition is made from state S1 to state S2B; and when a system administrator stop occurs, a transition is made from state S1 to state S2C. In each of the states, S2A, S2B, and S2C, one of the computers 10 or 20, enters the failover mode of operation. In that mode, the computer which previously was not servicing any requests from the workstations, becomes responsible for handling all requests to use the application programs. This failover mode of operation lasts for only a short period of time, such as one minute. Next, from the failover states S2A, S2B, and S2C, respective transitions are made to the states S3A, S3B, and S3C. In state S3A, a hardware error in one of the computers 10 and 20 is being fixed while the other computer is servicing requests from the workstations 80. Similarly in state S3B, a software error in one of the computers 10 or 20 is being fixed, while the other computer is servicing the workstation requests. Likewise, in state S3C, an administrator stoppage in one of the computers 10 or 20 is being worked on, while the other computer is servicing the workstation requests. From each of the states S3A, S3B, and S3C, a transition is eventually made back to state S1 or to another state S4. This transition is made back to state S1 if the one computer which stopped is made operable before the second computer stops. Otherwise, if both of the computers 10 and 20 stop concurrently, then a transition is made to state S4. Cluster 60 remains in state S4 until one of the computers 10 or 20 is made operable. When that occurs, a transition is made to state S3A if a hardware problem remains to be fixed; a transition is made to state S3B if a software problem remains to be fixed; and a transition is made to state S3C if a system administrator stoppage remains to be fixed. In each of the states S1, S3A, S3B, and S3C, the application programs in the cluster 60 are available for use by the workstations 80. Conversely, in each of the states S2A, S2B, S2C, S4, the applications programs in the cluster 60 are not available for use by the workstations 80. Now in accordance with the present invention, steps are provided for estimating the amount of time that is spent in the failover states S2A, S2B, and S3C; and, steps are provided for estimating the amount of time that is spent in state S4 where both of the computers 10 and 20 are inoperable. Then, using those estimations, the availability of an application program on the cluster 60 is determined. These steps will now be described in conjunction with FIGS. 5A and 5B. In step 1 of FIG. 5A, an estimate is made of the average number of hardware stops per year (HWSTOPS/YR) that occur in each one of the computers 10 and 20. As an example in step 1, the average number of hardware stops per year per computer is estimated to be 0.8. This step 1 estimate is herein called "A" for ease of reference in the subsequent steps. In step 2 of FIG. 5A, an estimate is made of the average time duration of each hardware stop (ATDHW). As an example in step 2, the average time duration of each hardware stop is estimated to be six hours. This step 2 estimate is herein called "B" for ease of reference in the subsequent steps. In step 3 of FIG. 5A, an estimate is made of the average number of software stops per year (SWSTOPS/YR) that occur in each one of the computers 10 and 20. As an example in step 3, the average number of software stops per year per computer is estimated to be 12. This step 3 estimate is herein called "C" for ease of reference in the subsequent steps. In step 4 of FIG. 5A, an estimate is made of the average time duration of each software stop(ATDSW). As an example in step 4, the time duration of each software stop is selected to be one hour. This step 4 estimate is herein called "D" for ease of reference in the subsequent steps. In step 5 of FIG. 5A, an estimate is made of the average number of system administrator stops per year (SASTOPS/YR) that occur in each one of the computers 10 and 20. As an example in step 5, the average number of system administrator stops per year per computer is estimated to be 20. This step 5 estimate is herein called "E" for ease of reference in the subsequent steps. In step 6 of FIG. 5A, an estimate is made of the average time duration of each system administrator stop (ATDSA). As an example in step 6, the average time duration of each system administrators stop is estimated to be one-half hour. This step 6 estimate is herein called "F" for ease of reference in the subsequent steps. In step 7 of FIG. 5A, an estimate is made of the average time duration of each failover time period (FT). As an example in step 7, the average time duration of each failover period is estimated to be one minute. This step 7 estimate is herein called "G" for ease of reference in the subsequent steps. Next, in step 8 of FIG. 5A, the estimates which were made in steps 1-7 are used to determine a virtual stoppage rate for each of the computers 10 and 20. In particular in step 8, this "single computer virtual stoppage rate" (SVCSR) is set equal to the sum of the quantities "A" of step 1, "C" of step 3, and "E" of step 5. A numerical example of this calculation is shown in step 9 wherein the single computer virtual stoppage rate is determined to be 32.8 stops per year. Next, in step 10, the estimates which were made in steps 1-7 are used to determine a virtual downtime period for each of the computers 10 and 20 which occurs at the above single computer virtual stoppage rate. In particular in step 10, this "single computer virtual downtime" (SCVD) is set equal to the sum of three products divided by the single computer virtual stoppage rate (SCVSR). Those three products are the quantities A times B, C times D, and E times F as estimated in step 1 through step 6. A numerical example of step 10 is shown in step 11 wherein the single computer virtual downtime is determined to be 0.817 hours. Next, in step 12 of FIG. 5A, a time interval which occurs between the virtual stoppages in each of the computers 10 and 20 is determined. In particular in step 12, this "single computer time between virtual stops" (SCTBVS) is set equal to the quantity 8760 divided by the single computer virtual stoppage rate (SCVSR). Here, 8760 is the number of hours per year. A numerical example of step 12 is shown in step 13 wherein the single computer time between virtual stops is determined to be 267.0 hours. Next, in step 14 of FIG. 5B, a ratio "R" is determined. This ratio "R" is an estimate of the probability of a single one of the computers 10 or 20 stopping due to a hardware stoppage or a software stoppage or a system administrative stoppage. To obtain this ratio "R", the single computer virtual downtime of steps 10 and 11 is divided by the single computer time between virtual stops of steps 12 and 13. A numerical example of step 14 is shown in step 15 wherein the single computer virtual downtime of step 11 and the single computer time between virtual stops of step 13 are used. Next, in step 16 of FIG. 5B, the ratio "R" of steps 14 and 15 is used to estimate the probability that both of the computers 10 and 20 stop concurrently. In particular in step 16, this "probability of concurrent stoppage" (PCS) is set equal to the quantity 2(R.sup.2). A numerical example of step 16 is provided in step 17 herein the ratio "R" from step 15 is used. Next, in step 18 of FIG. 5B, an estimate is made of the total time per year during which the computers 10 and 20 are concurrently stopped. In particular in step 18, this "concurrent stoppage per year" (CS/YR) is set equal to the probability of concurrent stoppage from step 16 times the quantity 8760. A numerical example of step 18 is provided in step 19 wherein the probability of concurrent stoppage from step 17 is used. Next, in step 20 of FIG. 5B, an estimate is made of the total stoppage time per year during which one of the computers 10 or 20 is in the failover mode of operation. In particular in step 20, this "failover stoppage time per year" (FS/YR) is set equal to the single computer virtual stoppage rate of step 8 times the failover time that is selected in step S7. A numerical example of step 20 is shown in step 21 wherein the single computer virtual stoppage rate of step 9 and the failover time of step 7 are used. Next, in step 22 of FIG. 5B, an estimate is made of the availability of the application programs within the cluster 60 to anyone of the workstations 80. In particular in step 22 of FIG. 5B, the "application availability" (AA) is set equal to 1 minus the sum of two stoppages divided by 8760. Those two stoppages which are summed are the concurrent stoppage per year of steps 18 and 19, and the failover stoppage per year of steps 20 and 21. A numerical example of step 22 is performed in step 23 wherein the concurrent stoppage per year of step 19 and the failover stoppage per year of step 21 are used. A preferred method of estimating the availability of an application program which runs on any computer in a cluster of two computers has now been described in detail. In addition, however, various changes and modification can be made to those details without departing from the nature and spirit of the invention. For example, the method of estimating the availability of an application program as shown in FIGS. 5A and 5B preferably is embodied in a computer program which is stored on a media that is readable by a personal computer. This is illustrated in FIG. 6 wherein item 120 represents a magnetic disk in which the computer program 130 is stored. Program 130 is read from the magnetic media 120 by a personal computer 140 where it is executed by an instruction processor 140a in an interactive fashion with an operator 150. Initially in the program 130, a visual display is generated on a monitor 140b, within the personal computer 140, which requests that the input parameters A-G be manually input by the operator 150. This is indicated by reference numeral 131. Program 130 waits until the input parameters A-G are manually input via the keyboard 140c in the personal computer, or until the program is terminated; and this is indicated by reference numeral 132. After the input parameters A-G are received, the program 130 generates the single computer virtual stoppage rate (SCVSR) and the single computer virtual downtime (SCVD) by performing step 8 through step 11 of FIG. 5A as indicated by reference numeral 133. Then program 130 estimates the concurrent stoppage per year (CS/YR) by performing step 12 through step 19 of FIGS. 5A and 5B; and then program 130 estimates the failover stoppage per year (FS/YR) by performing step 20-step 21 of FIG. 5B. This is indicated by reference numerals 134 and 135. Next, program 130 determines the application availability (AA) by performing step 22-step 23 of FIG. 5B as is indicated by reference numeral 136. Then, the application availability which is determined in step 136 is displayed by the program 130 on the monitor 140b; and this is indicated by reference numeral 137. All of the steps 131-137 can be repeated multiple times. Thus the operator 150 can input different values for the input parameters A-G and thereby see how a change in the input parameters affects the availability of the application program. This enables the operator 150 to select, by trial-and-error, a set of input parameters A-G which will result in a FIG. 1 system that provides a particular application availability which is desired. As another modification, information which is an important factor to the availability of an application program can be obtained by performing only a subset of the steps in FIGS. 5A and 5B. For example, the probability of concurrent stoppage (PCS) can be obtained by performing only step 1 thru step 6 and step 8 thru step 17. This PCs is particularly useful because it indicates the risk that none of the computers in the FIG. 1 system will be operable. As another modification, the process of FIGS. 5A and 5B can be changed such that it applies to a data processing system which is the same as shown in FIG. 1, except that the cluster 60 includes three computers. Initially, all requests on the network 70 to use the application programs are handled by a first one of the three computers. This mode of operation continues until a stoppage occurs in the first computer. Then a failover state is entered temporarily wherein the application programs are unavailable while the responsibility for handling requests to use the application programs is passed to a second one of the three computers. Thereafter, all requests to use the application programs are actually serviced by the second computer; and that mode of operation continues until a stoppage occurs in the second computer. Then a failover state is entered temporarily wherein the application programs are unavailable while the responsibility for handling requests to use the application programs is passed to the third computer. Thereafter, all requests to use an application program are actually serviced by the third computer. Subsequently when a stoppage occurs in the third computer, a failover state is temporarily entered only if either the first or second computer is operable; and from that failover state, the sequence continues as described above. Otherwise, if all three computers stop concurrently, then all requests to use the application programs will fail until one of the computers becomes operable. To account for this modification in the process of FIGS. 5A and 5B, only step 16 needs to be changed. Specifically, step 16 is replaced with step 16' as shown in FIG. 5B. There, the probability of concurrent stoppage of all three of the computers is estimated as 6(R).sup.3, where R is the ratio as determined by step 14. In like manner, the process of FIGS. 5A and 5B can be generalized to apply to a cluster of N computers, where N is 2, 3, 4, etc. To account for this modification, only step 16 needs to be replaced with step 16" as shown in FIG. 5B. There, the probability of concurrent stoppage of all N of the computers is estimated as (N!)(R).sup.N, where R is the ratio as determined by step 14 and (N!) is N factorial. As another modification, a less accurate estimation of the application availability (AA) can be obtained by setting some of the parameters "A"-"F" which are input in step 1-step 7, equal to zero. For example, the average number of system administrator stops per year in step 5 and the average time duration of each system administrator stop in step 6, can be set to zero. Likewise, a less accurate estimation of the probability of concurrent stoppage in step 16 can be obtained in the same fashion. Accordingly, it is to be understood that the present invention encompasses all such modifications and is defined by the appended claims.
|
Same subclass Same class Consider this |
||||||||||