Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Workload Balancing in a Distributed Environment

IP.com Disclosure Number: IPCOM000116848D
Original Publication Date: 1995-Nov-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 4 page(s) / 145K

Publishing Venue

IBM

Related People

Harrison, RB: AUTHOR [+4]

Abstract

In recent years there has been a trend (driven by cost effectiveness and performance considerations) towards distributed systems. In these, a service (e.g., a seat reservation system) is provided not by a single processor, or even several processors run by a single operating system but by a number of processors each with its own operating system. Such systems have advantages but bring the problem that a decision needs to be made as to which of the available processors any particular item of work should be given.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 35% of the total text.

Workload Balancing in a Distributed Environment

      In recent years there has been a trend (driven by cost
effectiveness and performance considerations) towards distributed
systems.  In these, a service (e.g., a seat reservation system) is
provided not by a single processor, or even several processors run by
a single operating system but by a number of processors each with its
own operating system.  Such systems have advantages but bring the
problem that a decision needs to be made as to which of the available
processors any particular item of work should be given.

      A simple current solution requires each user to be assigned to
a particular server permanently.  While simple this had the
disadvantages that it is not resilient against the failure of a
server and that if a server is very busy while other are idle work
cannot be moved to the underused systems.

      Another approach assigns each user to a server permanently as
above.  However, the server may itself route work to other servers.
This system is still not resilient and while it can balance the
workload it creates extra work (the re-routing) in the servers, the
very place that is heavily loaded.

      The system described here provides a distributed work load
system which will allow the clients to choose the "best" server of
those that are actually operating at the time.

The basic components of the distributed system are:
  1.  A system map describing the serving systems, the resources
(e.g.,
       transactions and programs and data) available on each such
system
       and the connections available between these systems and the
       clients (Item A in the Figure).  In principle there is one of
       these maps per complete system but in practice there would be
       backup maps to make the system more resilient.
  2.  Partial system maps containing the relevant subset of the
system
       map located within or near each client (Item B in the Figure).
       There would be many such maps in a complete system.  There
could
       be one per client though clients sharing a multi-user (e.g.,
       UNIX*) machine would probably share one map.
  3.  Means for distributing relevant parts of the system map to the
       client maps (on client request) and then maintaining these
copies
       if changes are made to the master system map (Item C in the
       Figure).
  4.  A means, located in each client for simulating the business of
       the systems and the delays of connections (Item D in the
Figure).
  5.  A means located in the clients for measuring the actual
       performances achieved by clients to which it has routed work
       (Item E in the Figure).
  6.  A means located in the clients for recording a history of
systems
       used and the performances achieved (Item F in the Figure).
  7.  An algorithm run in the clients to select...