Fabio Kon Roy Campbell M. Dennis Mickunas

1
2K A Distributed Operating System for Dynamic
Heterogeneous Environments

• Fabio Kon Roy Campbell M. Dennis
  Mickunas
• Klara Nahrstedt Francisco Ballesteros
• Department of Computer Science
• University of Illinois at Urbana-Champaign
• http//choices.cs.uiuc.edu/2K

2
Introduction

• Modern Computing Environments
• Hardware diversity embedded systems, PDAs,
  laptops, workstations, supercomputers.
• Software diversity different programming
  languages, component architectures, operating
  systems.
• Mobile computers
• Mobile users (different accounts in different
  systems)

3
Highly-Dynamic Environments

• Frequent changes
• 1. Structural changes
• HW and SW upgrades, OS patches, protocol updates
• 2. Dynamic changes
• availability of memory, CPU, and network
  bandwidth connectivity, physical location

4
Goal

• Facilitate management of dynamic, heterogeneous
  computing environments for
• Users
• System administrators
• Developers

5
2k Approach

• Network-Centrism
• user profiles, user environments
• services, applications, components
• What You Need Is What You Get (WYNIWYG)
• dynamic instantiation of applications and
  services
• automatic configuration

6
From where can we start?

• Run on multiple hardware platforms
• Run on top of different OSes
• Support different programming languages
• Support dynamism, late binding, components
• Solution
• OMG IDL
• CORBA ORBs
• Standard CORBA Services (Naming, Trading,
  Persistence)

7
But There Was A Problem

• Conventional ORBs were static
• Fixed threading model
• Fixed transport protocol IIOP (over TCP/IP)
• Fixed security strategy
• Fixed scheduling
• Inadequate for a wide range of applications
• Multimedia
• Mobile Computing
• Adaptive Applications

8
Reflective ORB

• Allows inspection and dynamic reconfiguration of
  the ORB internal engine.
• 1. dynamicTAO an extension of the TAO ORB
  Schmidt
• very complete
• big
• 2. LegORB a component-based ORB
• not complete, but expanding
• very small (minimal client 6K or 20K, minimal
  server 30K)

9
What is missing?

• We have
• Reflective Middleware layer supporting
  distributed objects in a dynamically configurable
  way.
• Standard services for Naming, Trading, Security.
• We still need
• Support for automatic configuration.
• Dynamic instantiation of user environments.
• Dynamic resource management.

10
2K Services

• Component Repository
• Automatic Configuration
• Distributed Resource Management
• Mobile Configuration Agents
• User Environment Service
• Distributed QoS Compilation Service
• Security, Data Management, ...

11
The 2K Architecture
12
Automatic Configuration Service

• Automatically instantiates applications and
  services by assembling their components.
• Based on
• Prerequisites static representation of
  dependencies.
• ComponentConfigurators dynamic representation
  of dependencies.

13
Prerequisites

• What a component needs to run
• nature of hardware resources
• share of the hardware resources
• software services (i.e., components) it requires
• Video Client example
• PC with Sound card
• 50 of CPU gt300MHz
• CORBA Video Service

14
Automatic Configuration Process

• 1. Fetches component code and prerequisites from
  the Component Repository.
• 2. Dynamically link component code into the
  application address-space.
• 3. Based on the prerequisites, repeats the
  process for other components.

15
Automatic Configuration Architectural Framework
fetch prerequisites
load application
Component Repository
Prerequisite Resolver
fetch components
return reference
Prerequisite Parser
QoS-Aware Resource Manager
Cache
16
Component Configurators

• Reify dynamic inter-component dependencies.
• Created on-the-fly by the Prerequisite Resolver.
• System and application software can inspect and
  reconfigure the Dependence Graph.

17
ComponentConfiguratorFramework

• Allows browsing, inspection, and reconfiguration
• Can be customized through inheritance
• Clear separation of concerns

18
Mobile Configuration Agents

• Suitable for Large-Scale Systems
• Useful for
• code distribution
• dynamic reconfiguration
• inspection

19
QoS-Aware Distributed Resource Management

• Global Resource Manager (GRM)
• one in each cluster
• maintains an approximate view of the cluster
  resource utilization
• Local Resource Manager (LRM)
• runs in each node
• exports the state of the local resources
• Has a Real-Time Scheduler (DSRT)
• admission control, reservation, and scheduling

20
Loading an Application with the Resource
Management Service

• 1. Client contacts local LRM, giving application
  name and QoS requirements
• 2. LRM performs admission test
• 3. Request forwarded to GRM
• 4. GRM forwards request to best candidate
• 5. Remote LRM performs admission test,
  reservation, and runs AutoConfig.

21
Experimental Results

• Testbed
• 2 Sun Sparc Ultra-60, two 360MHz CPUs
• 5 Sun Sparc Ultra-5, 333MHz CPU
• Solaris 7 OS
• 100Mbps Fast Ethernet

22
AutoConfig ServiceLoading Several Components
23
Mobile Configuration Agents

• Testbed
• Three Sparc Ultras, Solaris 7 _at_cs.uiuc.edu
• Three 333MHz PCs, Linux RH6.1 _at_escet.urjc.es
• Three 300MHz PCs, Linux RH6.1 _at_ic.unicamp.br
• 100Mbps Fast Ethernet (intra-domain)
• Public Internet (inter-domain)

24
Uploading a New Component to 9 Nodes
25
Related Work

• Automatic Configuration
• Customizable Operating Systems
• Java/Jini
• Distributed Resource Management
• Globus Foster and Kesselman 98
• Legion Grimshaw 97
• Software Architecture
• Dynamic reconfiguration
• ADLs

26
Ongoing Work

• User Environment Service
• Security Service
• Distributed QoS Compilation
• Multimedia Services
• Data Management Service
• Active Spaces (Ubiquitous Computing)

27
Conclusions

• As computing devices become pervasive in our
  society, we will encounter
• highly dynamic, heterogeneous environments
• complex dependencies
• difficult management
• 2K presents an integrated architecture that helps
  managing this complexity in a clean and efficient
  way.

28
How to contact us

• e-mail
• f-kon_at_cs.uiuc.edu
• 2K Web site
• http//choices.cs.uiuc.edu/2K

29
dynamicTAO Structure
30
Security Architecture

• Java Active Capabilities
• Flexible Security Policies
• Caching of Authorization Decisions
• Auditing

31
AutoConfig ServiceLoading Components of
Different Sizes