The ACE ORB and Distributed Resource Management

1
The ACE ORB and Distributed Resource Management

• David Fleeman
• Dr. Lonnie Welch

2nd Workshop of The ACE ORB (TAO) July 19,
2002 Arlington, VA
2
Overview

• Introduction
• Adaptive Resource Management (RM)
• RM Developer Perspective
• Advantages of using TAO
• What is missing?
• Conclusions
• References

3
Introduction

• Traditional scheduling approaches
• Fixed allocation of software to hardware
• Unresponsive to changes in the environment
• Resource management approach
• Optimally use a pool of computing resources
• Responsive to dynamic changes in the computing
  environment

4
RM Paradigm

• Monitor
• Analyze
• Control

5
Step 1 Monitor

• Real-time performance of software systems
• Resource usage of applications
• Available resources

6
Step 2 Analyze

• Will real-time requirements be violated?
• What will cause the violation?
• What reallocation actions can be taken to improve
  real-time performance?
• Move an application
• Change the QoS level of an application
• Replicate an application

7
Step 3 Control

• RM controls which resources (CPU, network
  bandwidth, memory, storage) that each application
  uses.
• RM controls how much of the resources that each
  application uses.

8
Application Areas of RM

• Shipboard computing
• Air Defense
• Command Control
• Autonomous satellite constellations

9
Shipboard Computing

• Dynamic war environment
• Air defense paths have been modeled and placed
  under RM control

10
Theater Battlespace Command and Control (TBC2)

• SPAWAR (Office of Naval Research (ONR) funded
  project)
• The goal of TBC2 is to develop a network centric
  architecture modeled upon FORCEnet that allows
  information and knowledge from multiple
  heterogeneous and distributed systems to be
  assimilated across or within command echelons and
  mission areas. The architecture will enable force
  coordination and its optimization, enable
  subordinates to keep higher command informed, and
  assure a comprehensive and reliable depiction of
  the battlespace across echelons.
• TBC2 will utilize the DeSiDeRaTa project as
  part of its Quality of Service (QoS) solution to
  interfacing C2 with Combat Systems. The plan is
  to utilize DeSiDeRaTa's Resource Manager (RM) to
  monitor the resources on each host and reallocate
  as necessary, the TBC2 applications that
  interface with the real-time combat systems.

11
Satellite Constellations
12
On-Board System Prototype
13
RM Middleware
14
RM Developer Perspective

• At first we supported our own communication
  library. We would need to make it support
• Heterogeneous applications
• Location transparency
• Communication across subnets
• TAO CORBA can do all these things.

15
Advantages of TAO CORBA

• Removes the need of supporting our own
  communications library
• Naming service allows location transparency and
  the communication across subnets
• Differences in hardware platforms solved
• Communication between Java, C, and C
  applications solved

16
Other Advantages

• Friendly enough to allow us to define a wrapper
  class to hide the communication details from the
  applications
• This wrapper allows C and C applications to use
  TAO CORBA to communicate with RM easily.
• Even though communication with RM requires TAO
  CORBA, applications are still able to use other
  communication mechanisms for their
  inter-application communication needs.

17
What Is Missing?

• Security and intrusion tolerance
• Fault tolerance

18
Security and Intrusion Tolerance

• React autonomously when a network link is
  compromised
• Removes burden from RM for detecting a subset of
  security violations

19
Fault Tolerance

• Replica and state management
• Active-passive model
• N-version programming (voting)
• When an active copy fails, then a passive copy
  automatically becomes active and continues where
  the previous active copy failed.

20
Conclusions

• There is a growing need for adaptive resource
  management of distributed pools of computing
  resources.
• TAO CORBA is proving to be a powerful
  communication mechanism to help meet this
  challenge.

21
References

• S. Anwar and L. Welch, Experience With TAO for
  Development of Adaptive Resource Management
  Middleware, 1st Workshop on The ACE ORB (TAO),
  August 2001.
• Binoy Ravindran, Lonnie R. Welch and Behrooz A.
  Shirazi, "Resource Management Middleware for
  Dynamic, Dependable Real-Time Systems," The
  Journal of Real-Time Systems, 20183-196, Kluwer
  Academic Press, 2000.
• Toni Marinucci, Anbuselvan Neelamegam, Brett
  Tjaden, Lu Tong, Lonnie Welch, Brian Goldman,
  Greg Greer, Deepak Kaul and Barbara Pfarr,
  Sensor Web Adaptive Resource Manager, NASA
  Earth Science Technology Conference (ESTC-2001),
  August 2001.
• S. Jain, L. R. Welch, D. M. Chelberg, Z. Tan, D.
  Fleeman, D. Parrott, B. Pfarr, M. C. Liu, C.
  Shuler, A Collaborative Problem Solving Agent
  for On-Board Real-time Systems, The 10th
  Workshop on Parallel and Distributed Real-Time
  Systems, April 2002.

22
More References

• Lonnie R. Welch, Paul V. Werme , Larry A.
  Fontenot, Michael W. Masters, Behrooz A. Shirazi,
  Binoy Ravindran and D. Wayne Mills, Adaptive
  QoS and Resource Management Using A Posteriori
  Workload Characterizations, The IEEE Real-Time
  Technology and Applications Symposium, 266-275,
  June 1999.
• Lonnie R. Welch, Binoy Ravindran, Robert D.
  Harrison, Leslie Madden, Michael W. Masters and
  D. Wayne Mills, Challenges in Engineering
  Distributed Shipboard Control Systems,
  Work-in-progress - The IEEE Real-Time Systems
  Symposium, 19-22, December 1996.
• Lonnie R. Welch, Prashant Shirolkar, Shafqat
  Anwar, Terry Sargeant, Behrooz A. Shirazi and
  Binoy Ravindran, Adaptive Resource Management
  for Scalable, Dependable Real-Time Systems
  Middleware Services and Applications to Shipboard
  Computing Systems, Work-in-Progress The IEEE
  Real-Time Technology and Applications Symposium,
  3-6, June 1998.