Browse Prior Art Database

Dynamic determination of a comparable capacity as a performance indicator for different server models and server configurations based on single server attributes

IP.com Disclosure Number: IPCOM000243558D
Publication Date: 2015-Oct-01
Document File: 4 page(s) / 112K

Publishing Venue

The IP.com Prior Art Database

Abstract

Workload balancing (WLB) across multiple heterogeneous distributed systems requires a way to compare different systems in terms of available capacity so that the WLB algorithm can determine efficiently which of the systems is best suited to serve a request, e.g. to process a SQL query. The algorithm needs to know the capacity of the target system and the current system utilization. Ideally, the capacity is not hard-coded in the WLB algorithm because that would require adjusting the algorithm for new hardware configurations, which becomes even more complex in virtualized environment, which may have very individual configurations.

Here we present an approach to dynamically determine the capacity of each server participating in the cluster that across which the workload is being distributed.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 41% of the total text.

Page 01 of 4

Dynamic Determination of a Comparable Capacity as a Performance Indicator for Different Server Models and Server Configurations Based on Single Server Attributes

1 Introduction and Motivation

Workload balancing (WLB) across multiple heterogeneous distributed systems requires a way to compare different systems in terms of available capacity so that the WLB algorithm can determine efficiently which of the systems is best suited to serve a request, e.g. to process a SQL query. The algorithm needs to know the capacity of the target system and the current system utilization. Ideally, the capacity is not hard-coded in the WLB algorithm because that would require adjusting the algorithm for new hardware configurations, which becomes even more complex in virtualized environment, which may have very individual configurations.

Here we present an approach to dynamically determine the capacity of each server participating in the cluster that across which the workload is being distributed.


2 State of the Art

Many of the existing workload balancing algorithms distribute individual requests of the workload using round-robin (RR). RR is very simple and does not require any indication for the capacity of the servers. However, heterogeneous systems suffer due to a potentially unbalanced workload distribution. Systems with a high capacity may be under-utilized and systems with a small capacity may be over-utilized.

Another often used alternative are weight-based load balancing algorithms. Each system has a weight corresponding to its capacity, and the WLB algorithm uses static lookup tables to determine the distribution for the requests across the systems.


2.1 Examples
1.) WebSphere MQ Clustering - Workload balancing - Round Robin Processing

The workload algorithm selects destinations based on: the state of the channel, the availability of the queue manager, and the availability of the queue. https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/websphere_mq_clustering_ workload_balancing_dick_hamilton14?lang=en


2.) Load Balancing for EJBs and RMI Objects

Weight-Based Load Balancing


This algorithm applies only to EJB and RMI object clustering.

Weight-based load balancing improves on the round-robin algorithm by taking into account a pre- assigned weight for each server.

You can use the Server -> Configuration -> Cluster tab in the Administration Console to assign each server in the cluster a numerical weight
between 1 and 100, in the Cluster Weight field. This value determines what proportion of the load the server will bear relative to other servers. http://docs.oracle.com/cd/E13222_01/wls/docs81/cluster/load_balancing.html


2.2 Conclusion


Existing WLB algorithms may have no or only static input to calculate the distribution of the workload over all servers in the cluster. The input is not based on the actual performance indicators of the participating servers. This results in a sub-optimal utilization of the servers in the cluster - se...