Browse Prior Art Database

Algorithm for self-optimising workload management in a cluster

IP.com Disclosure Number: IPCOM000020704D
Original Publication Date: 2003-Dec-10
Included in the Prior Art Database: 2003-Dec-10
Document File: 2 page(s) / 55K

Publishing Venue

IBM

Abstract

This article describes an algorithm that uses knowledge local to a routing application to dynamically select a routing strategy to optimally balance a workload within a message-queueing cluster, by allocating spare resources effectively. The algorithm avoids having to query the state of destination systems and hence removes the delay and possible instability in routing choice inherent in a closed-loop routing system.

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 52% of the total text.

Page 1 of 2

Algorithm for self-optimising workload management in a cluster

The challenge in constructing a workload balancing algorithm for routing messages in a cluster is to make it simple enough so as not to significantly impact the performance of the putting application by taking overly long to choose the destination. The decrease in performance will of course be dependent on the number of available destinations. Algorithms that query the status of all possible desinations in real time to attempt to select optimally have been attempted using IBM's* WebSphere* MQ message-queueing product, but have resulted in instability - when all destinations are identical in capacity and configuration, such algorithms do not converge to equal distribution of work because of the too great delay in the feedback loop.

    If we rule out algorithms that require getting knowledge from remote locations synchronously, we can still envisage algorithms that provide a degree of self-optimisation in the way messages are routed. These must be based on knowledge gathered locally which could be accessed quickly when making the choice as to where to route the message. This involves making the real-time choice based on a model on how the system is expected to behave rather than the actual performance of remote nodes. The model could then be adapted asynchronously to reflect actual performance

    An example of how such a system could work follows. It is reasonable to expect that the overall performance of the system will decrease if more messages are passing through it. We do not need to monitor the actual performance of remote nodes to know this. Hence a workload balancing algorith for a routing application could monitor the number of messages sent to all instances of a particular cluster queue. At a trigger point of message volume, the program would trigger a scr...