Browse Prior Art Database

Load balancing in a server cluster environment with application's participation

IP.com Disclosure Number: IPCOM000198303D
Publication Date: 2010-Aug-04
Document File: 4 page(s) / 56K

Publishing Venue

The IP.com Prior Art Database

Abstract

The core idea of this invention is: Provide a method in the application server side for application developers to claim their intentions on load balancing control. These intentions are associated with some parts of the application code. During application server runtime, when the associated code is executed, the dispatcher can be notified on such intentions information and then take actions accordingly. Moreover, in our idea, the dispatcher can choose to satisfy an intention or not, based on the intention itself as well as other configurations and runtime information.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 34% of the total text.

Page 1 of 4

Load balancing in a server cluster environment with application '

Load balancing (also known as terms like workload management or load dispatching ) is one of the mostimportant functions provided in a server cluster environment (for example, an application server cluster ).

Normally, the load balancing function is provided by a dispatcher which is in front of the server cluster . The dispatcher is in charge of distributing requests/workloads across the backend servers . It recieves a request and assigns the request to one of the backend servers based on some predefined rules . These rules could be simple rules such as Random or Round -Robin, or complex rules taking account of server configurations, server runtime states, request types, SLA (Service Level Agreements ), current time, etc.

In current designs and implementations of application server clusters , no matter what rules are being used by the dispatcher , load balancing is always designed to be application /user transparent, which means, no application participation is needed , or expected. There are good reasons for keeping this kind of transparency , so that users and application developers do not need to have knowledge about load balancing or be aware of its existing . The application server cluster (includes the dispatcher and backend servers as a whole ) can take control of load balancing autonomically . This greatly simplifies the use of the application server cluster .

However, in some cases, existing load balancing methods are not satisfying . The reason is that the dynamic capability of existing load balancing methods is based on feedback from monitoring .

Consider the following situation as an example : a piece of application code extracts millions of data from databases and does sophisticated computing upon those data to generate a result , which will consume a great mount of CPU cycles and memory spaces . In current solutions, the dispatcher would not be able to find out this and take proper actions (for example, stop sending new requests to that server) until the code was executed and drove a server 's CPU/Memory up to a threshold . The problems here are clear :
1) There would be latencies between the situation occurred and the dispatcher took actions .
2) Sometime, the server could be extremely overloaded once the code was executed , and it would be hard for the dispatcher to communicate with the server at that time .

Consider another case: due to some application logic reasons , a request might want to make exclusively use of a server for some time but will not bring any obvious status change (CPU, memory, IO, network, etc) to that server, existing load balancing solutions can not be aware of this situation and satisfy the requirement .

From the above examples, we could see that current "application transparent" load balancing solutions could not satisfy users ' requirements in some cases . To solve such problems, we need to design a new solution that can proa...