Processing incoming transactions based on resource utilization status of backend systems in an appliance cluster

• US 10,320,889 B2
• Filed: 11/30/2017
• Issued: 06/11/2019
• Est. Priority Date: 09/30/2013
• Status: Active Grant

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Chang, Chun-Fei, Liu, Jeffrey Ch, Tseng, Joey Hy, Shih, Hao-Ting
• Primary Examiner(s): Lee, Gil H
• Assistant Examiner(s): Guzman, Javier O
• Application Number:
  US15/826,829
• Publication Number:
  US 20180084033A1
• Time in Patent Office: 558 Days
• CPC Class Codes: G06F 11/00 Error detection; Error correction; Monitoring error detection, correction or monitoring in information storage based on relative movement between record carrier and transducer G11B20/18; monitoring, i.e. supervising the progress of recording or reproducing G11B27/36; in static stores G11C29/00
• CPC Class Codes: G06F 11/3433 for load management allocation of a server based on load conditions G06F9/505; load rebalancing G06F9/5083; redistributing the load in a network by a load balancer H04L67/1029
• CPC Class Codes: G06F 2201/81 Threshold
• CPC Class Codes: G06F 2201/87 Monitoring of transactions
• CPC Class Codes: G06F 2201/88 Monitoring involving counting
• CPC Class Codes: G06F 9/00 Arrangements for program control, e.g. control units program control for peripheral devices G06F13/10
• CPC Class Codes: G06F 9/466 Transaction processing
• CPC Class Codes: G06F 9/50 Allocation of resources, e.g. of the central processing unit [CPU]
• CPC Class Codes: G06F 9/505 considering the load
• CPC Class Codes: H04L 12/4641 Virtual LANs, VLANs, e.g. virtual private networks [VPN] LAN interconnection over a bridge based backbone H04L12/462; encapsulation techniques H04L12/4633; routing of packets H04L45/00; packet switches H04L49/00; virtual private networks for security H04L63/0272
• CPC Class Codes: H04L 63/0209 Architectural arrangements, e.g. perimeter networks or demilitarized zones
• CPC Class Codes: H04L 67/10 in which an application is distributed across nodes in the network software deployment G06F8/60; multiprogramming arrangements G06F9/46

Abstract

A first reverse proxy appliance of the plurality of reverse proxy appliances receives an incoming transaction. A machine logic determines that the incoming transaction cannot be directly processed by the first reverse proxy appliance based, at least in part, upon the current threshold level of the first reverse proxy appliance and the current transaction count of the first reverse proxy appliance. Responsive to the determination that the incoming transaction cannot be directly processed by the first reverse proxy appliance, a second reverse proxy appliance of the plurality of reverse proxy appliances and a third reverse proxy appliance of the plurality of reverse proxy appliances negotiate in order to determine that the third reverse proxy appliance will process the incoming transaction. Responsive to the negotiating, the incoming transaction is sent to the third reverse proxy appliance.

Claims

1. A method comprising:

receiving, by a first reverse proxy appliance of a plurality of reverse proxy appliances, an incoming transaction, wherein the first reverse proxy appliance is part of a distributed computer system that includes the plurality of reverse proxy appliances that share a common backend sub-system, with each given reverse proxy appliance of the plurality of reverse proxy appliances being;

(i) configured to perform service level monitoring (SLM) to prevent the common backend sub-system from being overwhelmed by unanticipated burst messages, (ii) characterized by a current threshold level which is a sum of a quantity of transactions that can be directly processed by the given reverse proxy appliance and a quantity of transactions that can be processed by other reverse proxy appliance(s) on behalf of the given reverse proxy appliance, and (iii) further characterized by a current transaction count;

determining, by machine logic, that the incoming transaction cannot be directly processed by the first reverse proxy appliance based, at least in part, upon a current threshold level of the first reverse proxy appliance being less than a sum of a current transaction count of the first reverse proxy appliance and a size of the incoming transaction;

responsive to the determination that the incoming transaction cannot be directly processed by the first reverse proxy appliance, negotiating, by a second reverse proxy appliance of the plurality of reverse proxy appliances as a negotiation device, with a third reverse proxy appliance of the plurality of reverse proxy appliances to process the incoming transaction; and

sending the incoming transaction to the third reverse proxy appliance for processing of the incoming transaction on behalf of the first reverse proxy appliance by the third reverse proxy appliance lending at least one transaction unit to the first reverse proxy appliance.

2. The method of claim 1 further comprising:

determining, by machine logic, that the third reverse proxy appliance has a largest current threshold level of the reverse proxy appliances of the plurality of reverse proxy appliances; and

responsive to the determining that the third reverse proxy appliance has the largest current threshold level of the reverse proxy appliances of the plurality of reverse proxy appliances, selecting the third reverse proxy appliance for negotiation with the second reverse proxy appliance.

6. The method of claim 1, wherein the common backend sub-system comprises a server for executing a computation on the incoming transaction.

3. A method comprising:

receiving, by a first application level firewall (ALF) of a plurality of ALFs, an incoming transaction, wherein the plurality of ALFs are part of a distributed computer system that includes a plurality of reverse proxy appliances that share a common backend sub-system, with each given reverse proxy appliance of the plurality of reverse proxy appliances being;

(i) configured to perform service level monitoring (SLM) to prevent the common backend sub-system from being overwhelmed by unanticipated burst messages, (ii) characterized by a current threshold level which is a sum of a quantity of transactions that can be directly processed by the given reverse proxy appliance and a quantity of transactions that can be processed by other reverse proxy appliance(s) on behalf of the given reverse proxy appliance, and (iii) further characterized by a current transaction count;

determining, by machine logic, that the incoming transaction cannot be directly processed by the first ALF based, at least in part, upon a current threshold level of the first ALF being less than a sum of a current transaction count of the first ALF and a size of the incoming transaction;

responsive to the determination that the incoming transaction cannot be directly processed by the first ALF, negotiating, by a second ALF of the plurality of ALFs as a negotiation device and a third ALF of the plurality of ALFs, to determine that the third Al will process the incoming transaction; and

responsive to the negotiation, sending the incoming transaction to the third ALF for processing of the incoming transaction on behalf of the first reverse proxy appliance by the third reverse proxy appliance lending at least one transaction unit to the first reverse proxy appliance.

4. The method of claim 3 further comprising:

determining, by machine logic, that the third ALF has a largest current threshold level of the ALFs of the plurality of ALFs; and

responsive to the determination that the third ALF has the largest current threshold level of the ALFs of the plurality of ALFs, selecting the third ALF for negotiation with the second ALF.

5. A method comprising:

receiving global current threshold level data including information indicative of current threshold levels for a quantity of transactions that can be handled by each reverse proxy appliance (RPA) of a plurality of RPAs, wherein the plurality of RPAs are part of a distributed computer system, with each given RPA of the plurality of RPAs being;

(i) configured to perform service level monitoring (SLM) to prevent a common backend sub-system from being overwhelmed by unanticipated burst messages, (ii) characterized by a current threshold level which is a sum of a quantity of transactions that can be directly processed by the given reverse proxy appliance and a quantity of transactions that can be processed by other reverse proxy appliance(s) on behalf of the given reverse proxy appliance, and (iii) further characterized by a current transaction count;

receiving backend load data including information indicative of backend load(s) on a set of backend sub-system(s) served by the plurality of RPAs; and

adjusting a current threshold level of a first RPA of the plurality of RPAs based, at least in part, upon both of the following;

(i) the global current threshold level data of the first RPS being less than a sum of a current RPA transaction count for the first RPA and a size of an incoming transaction, and (ii) the backend load data wherein the current threshold level of the first RPA is adjusted by a second RPA processing the incoming transaction on behalf of the first RPA by lending the first RPA at least one transaction unit.

7. The method of claim 5, further comprising:

determining that the current threshold level of the first RPA is lower than the global current threshold level data;

determining that the backend load data is less than a predefined level; and

in response to determining that the current threshold level of the first RPA is lower than the global current threshold level data and that the backend load data is less than the predefined level, transferring processing of a new incoming transaction from the first RPA to another RPA from the plurality of RPAs.

8. The method of claim 5, further comprising:

determining that the current threshold level of the first RPA is higher than the global current threshold level data;

determining that the backend load data is less than a predefined level; and

in response to determining that the current threshold level of the first RPA is higher than the global current threshold level data and that the backend load data is less than the predefined level, processing a new incoming transaction by the first RPA.

9. The method of claim 5, further comprising:

determining a spared transaction threshold unit for the first RPA, wherein the spared transaction threshold unit is based on a past average transaction handling rate of the first RPA minus a current transaction count of the first RPA;

determining that the spared transaction threshold unit for the first RPA is greater than a spared transaction threshold unit for another RPA; and

in response to determining that the spared transaction threshold unit for the first RPA is greater than the spared transaction threshold unit for said another RPA, processing a new incoming transaction by the first RPA.

10. The method of claim 5, further comprising:

determining a spared transaction threshold unit for the first RPA, wherein the spared transaction threshold unit is based on a past average transaction handling rate of the first RPA minus a current transaction count of the first RPA;

determining that the spared transaction threshold unit for the first RPA is less than a spared transaction threshold unit for another RPA; and

in response to determining that the spared transaction threshold unit for the first RPA is less than the spared transaction threshold unit for said another RPA, transferring processing of a new incoming transaction from the first RPA to said another RPA from the plurality of RPAs.