Transparent Adaptive Resource Management for Distributed Systems

1
Transparent Adaptive Resource Management
forDistributed Systems
Jaiganesh Balasubramanian Ossama Othman Dr.
Douglas C. Schmidt jai, ossama,
schmidt_at_dre.vanderbilt.edu
Department of Electrical Engineering and Computer
Science Vanderbilt University, Nashville
2
Distributed Systems

• Typical issues with distributed systems
• Heterogeneous environments
• Concurrency
• Large bursts of client requests
• 24/7 availability
• Stringent QoS requirements
• Examples of distributed systems
• E-commerce
• Online trading systems
• Mission critical systems
• Defense
• Ship systems

3
Motivation

• Development and maintenance of QoS-enabled
  distributed systems
• Non-trivial
• Requires expertise that application developers
  often lack
• Solution Middleware (e.g. CORBA)
• Can shield distributed system developers from the
  complexities involved with developing distributed
  applications
• Can facilitate manipulation of QoS requirements
  and management of resources

4
Distributed System Resource Management

• Middleware can alleviate resource management
  difficulties
• Doing so in a transparent and efficient manner is
  difficult
• Managing resources transparently is important for
  legacy DRE systems
• Often cannot be easily modified to introduce
  support for improved distributed resource
  management
• May not be feasible to do so
• Middleware in use may need to be enhanced to
  support this functionality
• Such an enhancement can be found in a
  middleware-based load balancing service

5
Middleware-Based Load Balancing

• Load balancing service can be used to manage
  resources for middleware-based distributed
  systems
• Can improve the efficiency and overall
  scalability of a distributed system
• Allows additional components to be added to
  distributed systems with minimal impact to
  performance
• Improves availability due to inherent redundancy
• Can be composed with other services (e.g. fault
  tolerance, security, etc)
• Can take into account request content

6
Basic Scenario

• Multiple clients making request invocations
• Potentially non-deterministic
• Members
• Multiple instances of the same object
  implementation
• Object groups
• Collections of members among which loads will be
  distributed equitably
• Logically a single object
• Load balancer
• Transparently distributes requests to members
  within an object group

7
TAO Load Balancer (Cygnus)

• Cygnus makes it easier to develop distributed
  applications in heterogeneous environments
  providing application transparency, scalability,
  flexibility, adaptability and interoperability.
• Uses the following strategies
• - RoundRobin
• - Random
• - LeastLoaded

8
Load Balancing Strategies

• Client binding granularity
• Per-session
• Client permanently forwarded to a replica
• Per-request
• Requests forward on clients behalf
• On-demand
• Client can be rebound to another replica whenever
  necessary
• Balancing policy
• Non-adaptive
• No load feedback used when binding clients
• Adaptive
• Load feedback taken in to account

9
Load Balancing Architectures

• Load balancing architecture comprised of a
  combination of client binding granularity and
  balancing policy
• Given the strategies just described, there are
  six possible architectures
• Three common architectures
• Non-adaptive per-session
• Adaptive per-request
• Adaptive on-demand

10
Load Balancer Components

• Load Monitor
• Provides load feedback
• Load Analyzer
• Determines location and member load conditions
• Member Locator
• Binds client to appropriate object group member
• Load Alert
• Facilitates load control (load shedding)
• Load Manager
• Mediates all interactions between load balancer
  components

11
Load Monitor

• Facilitates feedback
• Monitor and report loads
• Load monitoring is location-oriented
• The loads at a given location are monitored and
  reported
• Contrast with loads on a given object group
  member

12
Load Analyzer

• Load Analyzer
• Decides which member will receive the next client
  request
• Determines load condition at each location
• Induces load shedding
• Extensible load balancing strategies
• Set via the PropertyManager interface
• Each object group may use a different strategy

13
Member Locator

• Implements the Interceptor design pattern
• Transparently forwards client requests to member
  retrieved from the load analyzer
• In CORBA, redirection induced via standard GIOP
  LOCATION_FORWARD message
• Conforming client side ORB will transparently
  re-issue request to member chosen by load
  balancer

14
Load Alert

• Facilitates control aspect of load balancing
• Load shedding
• Only used for adaptive load balancing strategies
• Forwards client requests back to load balancer

15
Load Manager

• Mediates interactions between all load balancer
  components
• Manages object groups
• Manages load monitor and load alert location maps
• Acts as a specialized event channel
• Load events are published by load monitors
• Load events are consumed by load analyzers

16
Load Balancing Instructions
17
Future Work

• Define stateful load balancing model
• Decentralized load balancing
• Reduced network overhead
• Improved reliability
• Integrate multicast support
• Examine compatibility with real-time systems
• Examine similarities and parallels to dynamic
  scheduling

18
Concluding Remarks

• Load balancing architecture and model is
• Flexible
• Extensible load balancing strategies
• Allows both non-adaptive and adaptive (including
  self-adaptive) strategies to be used
• Freedom to implement in a variety of ways
• Centralized
• Decentralized / Federated / Cooperative
• Hierarchical
• Generic
• Supports multiple object groups
• Not application-specific
• Familiar
• Uses many of the same group management concepts
  found in existing fault tolerance models

19
References

• Ossama Othman, Jaiganesh Balasubramanian, Douglas
  C. Schmidt
• The Design of an Adaptive Load Balancing
  and Monitoring Service
• http//www.cs.wustl.edu/schmidt/IWSAS_2003.p
  df
• Ossama Othman, Jaiganesh Balasubramanian, Douglas
  C. Schmidt
• Performance Evaluation of an Adaptive Load
  Balancing and Monitoring Service
• http//www.cs.wustl.edu/schmidt/ICDCS_2004.p
  df