Routing transactions in the presence of failing servers

• US 5,475,813 A
• Filed: 07/18/1994
• Issued: 12/12/1995
• Est. Priority Date: 07/18/1994
• Status: Expired due to Fees

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Sairamesh, Jakka, Ferguson, Donald F., Cieslak, Randall A.
• Primary Examiner(s): Beausoliel, Jr., Robert W.
• Assistant Examiner(s): Decady, Albert
• Application Number:
  US08/277,377
• Time in Patent Office: 512 Days
• Field of Search: 395/575, 371/7, 371/4, 371/5.1, 379/273, 379/219, 379/220, 379/221, 379/273, 370/16, 370/5.1
• US Class Current: 714/4.1
• CPC Class Codes: G06F 11/142 Reconfiguring to eliminate the error group management mechanisms in a peer-to-peer network H04L67/1044

Abstract

Failures are detected in servers of a transaction processing system, and transactions are routed to less failure prone servers in the system. Servers in the transaction processing system which are faulty for some transaction classes but good for others are detected, and such servers are used in a judicious manner to maximize the throughput and minimize the response time of the system. Error prone servers are occasionally probed to determine if they have improved in terms of their error characteristics. The mechanism implemented consists of three elements. The first is the selection of a routing algorithm based on the state of the transaction processing system. Second, transactions are used to probe systems considered too faulty for use in order to determine if they have improved in terms of their failure characteristics. Finally, soft ABENDs are detected. The algorithm for transaction routing to detect and control the problem of failing servers in a transaction processing system consists of two parts: The first part routes transactions to servers based on the length of the server queues, the response time of the transactions (i.e., queuing delay plus processing delay), and the perceived failure rate. The second part of the algorithm ensures that error prone servers are not completely ignored. Occasional transactions are used to probe servers in order to determine if they have improved in terms of their error characteristics.

Claims

1. A method for routing transactions in a transaction processing system in which servers can fail comprising the steps of:

estimating a probability of a transaction failure for each server and each transaction class;

estimating an arrival rate of each transaction class at each router and at each server;

determining a queue length of transactions of each class waiting at each server;

determining failure probabilities for each server in the transaction processing system based on the estimates of a probability of a transaction failure and the arrival rate for each transaction class and a number of transactions of each class waiting at the server;

routing transactions to servers that have failure rates below a predetermined threshold; and

if multiple servers satisfy the predetermined threshold, then choosing a server using statistical data about transaction arrival rates, response times, failure probabilities, and queue lengths of transactions per class at the servers.

2. A method for routing transactions in a transaction processing system in which servers can fail comprising the steps of:

estimating a probability of a transaction failure for each server and each transaction class;

estimating an arrival rate of each transaction class at each router and at each server;

determining a queue length of transactions of each class waiting at each server;

determining failure probabilities for each server in the transaction processing system based on the estimates of a probability of a transaction failure and the arrival rate for each transaction class and a number of transactions of each class waiting at the server;

routing transactions to servers that have failure rates below a predetermined threshold; and

detecting a decrease in a failure rate of servers that are ignored in the routing step because they were considered too faulty.

3. The method recited in claim 2 further comprising the step of detecting the presence of soft abnormal endings of transactions at each server, a soft abnormal ending occurring when a server returns a code that indicates success for a transaction that has actually failed.

4. The method recited in claim 3 wherein said step of detecting the presence of soft abnormal endings of transactions is performed by the step of comparing response times of transactions to statistical data of response times for successful transactions.

5. The method recited in claim 4 wherein the statistical data is a histogram of observed response times.

6. The method recited in claim 4 further comprising the steps of:

setting a threshold p and defining v to be p times the number of observations used to make the histogram; and

identifying a transaction with a response time that falls into a histogram bin that has less than v elements as a soft abnormal ending.

7. A method for routing transactions in a transaction processing system in which servers can fail comprising the steps of:

estimating a probability of a transaction failure for each server and each transaction class;

estimating an arrival rate of each transaction class at each router and at each server;

determining a queue length of transactions of each class waiting at each server;

determining failure probabilities for each server in the transaction processing system based on the estimates of a probability of a transaction failure and the arrival rate for each transaction class and a number of transactions of each class wailing at the server;

routing transactions to servers that have failure rates below a predetermined threshold; and

monitoring H(i,j), the number of class i transactions at server j.

8. Method for routing transactions in a transaction processing system in which servers can fail and wherein transactions of a certain class are not currently being routed to one or more servers because of a high failure rate, comprising the steps of:

estimating a probability of a transaction failure for each server and each transaction class;

estimating an arrival rate of each transaction class at each router and at each server;

determining a queue length of transactions of each class waiting at each server;

determining failure probabilities for each server in the transaction processing system based on the estimates of a probability of a transaction failure and the arrival rate for each transaction class and a number of transactions of each class waiting at the server;

routing transactions to servers that have failure rates below a predetermined threshold;

sending a limited number of transactions to said one or more servers; and

determining if a failure rate of said one or more servers has decreased based on a return of a code indicating a success or failure of transactions sent to the systems.

9. The method recited in claim 8 where in the step of determining if a failure rate has decreased comprises the steps of:

waiting for a specified number of transaction completions to occur;

recomputing a transaction failure rate for said one or more servers assuming that a transaction has completed successfully, even though no transaction has actually been routed to said one or more servers; and

as an estimated failure probability decreases, sending a transaction to said one or more servers to test of said one or more servers has improved.