Download as PDF, PPTX
Uploaded byUniversidad Carlos III de Madrid
Towards a real-time reconfiguration service for distributed Java
The document proposes a reconfiguration service for distributed real-time Java applications. It introduces extensions to support real-time parameters like scheduling, release, memory and network parameters. The service allows adding and removing tasks from distributed Java VMs. It evaluates a priority-based partitioning policy for task allocation. The policy checks feasibility and assigns priorities. Evaluation shows reconfiguration time increases with number of tasks and VMs. Asynchronous events have the highest cost. Ongoing work aims to support different scheduling policies and adaptation using real-time OSGi.
More Related Content
Similar to Towards a real-time reconfiguration service for distributed Java
Towards a real-time reconfiguration service for distributed Java
- 1. Towards a ReconfigurationService for Distributed Real-Time Java* Pablo Basanta-Val Marisol García-Valls DREQUIEM LAB. Universidad Carlos III de Madrid * This work has been presented at REACTION Workshop 2012. Collocated with IEEE RTSS 2012 Symposium at Puerto Rico
- 2. Outline • Context &contribution ▫ Online scheduling & open systems • The reconfiguration service ▫ Distributed Java approach Overview of real-time parameters Reconfiguration points ▫ Contributed Reconfiguration service Proposed Extensions Evaluation of a policy • Conclusion and future work 2 REACTION WORKSHOP
- 3. Context & Introduction •Many real-time systems consider admission control as a offline line feature ▫ Clear advantages like exact algorithms • However more and more systems are dynamic and applications may appear and disappear ▫ Real-time CLOUD computing or real-time Open Systems ▫ How to make dynamic admission control efficient ! • Admission control for real-time performance ▫ Exact algorithms tend to be very costly ! 3 REACTION WORKSHOP
- 4. Context & Introduction Areal-time reconfiguration service in a nutshell • A Real-Time Reconfiguration Service for Distributed Real- Time Java ▫ Idea: To define a template for reconfiguration in distributed real- time Java applications It may customized for different applications ▫ Benefits: Real-time Java community, and DRTSJ (The Distributed Real-Time Specification for Java) ▫ Contribution: Extensions to current APIS Real-time Reconfiguration Service Example global partitioner algorithm with some performance results REACTION WORKSHOP 4
- 5. Distributed Real-Time Java middleware •Based on DREQUIEMI ▫ Layered approach for Distributed Real-time Java Infrastructure Distribution Common Services Applications • Currently, it consists of three main technologies extending RTSJ ▫ Based on Java’s RMI, {RT}-CORBA , and TT tenets 5 REACTION WORKSHOP
- 6. Distributed RT Java QoS/RTconfiguration parameters • Based on the model proposed by RTSJ • They characterize ▫ Application release pattern ▫ Scheduling specific parameters ▫ Memory parameters ▫ Processing group options ▫ Other internal decisions Thread-pool Connection Pool Memory Area pool QoS parameters in distribution layer Meaning in DREQUIEMI Scheduling Parameters «Priority» Priority used during the up-call at the server Release Parameters «Release Time, Period, Deadline, and Cost» Invocation pattern at the server according to the real-time scheduling theory Processing Group Parameters «Release Time, Period, Deadline and Cost» Group patterns at the server according to the real-time scheduling theory Memory Parameters Parameters used by the garbage collector at the server Thread Pool Thread pool used at the sever to manage remote invocations Connection Pool Connection pool used at the client to carry out the remote invocation Memory Area Pool Memory area pool used at the server to accept remote invocations port The IP port on which the remote object is accepting incoming messages RemoteStub The stub with the remote reference to the remove object EventCommonInt. A remote object which allows subscriptions and may be remotely triggered. 6 REACTION WORKSHOP
- 7. Reconfiguration points • Three reconfigurationpoints in Distribute RT Java ▫ Resources, distribution, and components • Contributed reconfiguration applies to resource management/rescheduling: ▫ Location of tasks in Remote Nodes ▫ Processor, network, and memory REACTION WORKSHOP 7 reconf
- 8. Reconfiguration Service Introducing Networkparameters • RTSJ does not support the network ▫ Centralized systems only! • But it could be extended with it ▫ Adding new classes to the RTSJ • Network parameters example: ▫ Priority for the IP packet (router) ▫ A maximum bit rate ▫ A complete RSVP stack, etc. Scheduler DistributedScheduler Real-time Java Distributed Real-time Java uses MemoryParameters SchedulingParametersuses 3ResourcesScheduler NetworkParameters uses Serializable ReconfigurationService uses Schedulable RemoteSchedulable 8 REACTION WORKSHOP
- 9. Reconfiguration Service Distributed Scheduler •Based on RTSJ’s scheduler • It allows invokers to assign schedulables to the task set ▫ Allocation ▫ Deallocation • Each schedulable defines: ▫ Release parameters, ▫ memory parameters ▫ Processing parameters ▫ Network Parameters ▫ Scheduling Parameters 01: public interface DistributedScheduler 02: extends java.rmi.Remote { 03: boolean addIfFeassible( 04: Schedulable s, 05: ReleaseParameters rs, 06: MemoryParameters mp, 07: ProcessingGroupParameters pgp, 08: NetworkParameter np ) 09: throws RemoteException; 10: boolean removeIfFeassible(Schedulable s) 11: throws RemoteException; 12:} 9 REACTION WORKSHOP
- 10. Reconfiguration Service Reconfiguration Service •To introduce reconfiguration on the previous system ▫ The reconfiguration process is modelled as a real-time schedulable • Based on that, the reconfiguration service ▫ reconfiguration service = DistributedScheduler + scheduling info for DistributedScheduler ▫ The ReconfigurationService executes on top of a scheduler. 01: public interface ReconfigurationService extends 02 DistributedScheduler, Schedulable{ 03: MemoryParameters getMemoryParameters() 04: throws RemoteException; 05: ProcessingGroupParameters 06: getProcessingGroupParameters() 07: throws RemoteException; 08: ReleaseParameters 09: getReleaseParameters() 10: throws RemoteException; 11: Scheduler getScheduler(); 12: throws RemoteException; 13: SchedulingParameters getSchedulingParameters(); 14: throws RemoteException; 15: NetworkParameters getNetworkParameters(); 16: throws RemoteException; 17: void setMemoryParameters(MemoryParameters mp) 18: throws RemoteException; 19: void setProcessingGroupParameters( 10 REACTION WORKSHOP
- 11. Tested Scheduling Policy(1/4) End-2-End Flow-Shop • Flow-Shop ▫ Defined as a sequence of subtasks that execute in order (i.e. with precedence constraints). • Each end-to-end transaction (Γj | j 1..M) is defined as follows: ▫ Global deadline (Dj) ▫ A global period (Tj) ▫ A set of j n schedulable segments {Sj 1….Sj n} A local execution priority (Pj n) for each end-to-end transaction segment (Sj n). A local worst-case execution time (Cj n) for each segment (Sj n). 11 REACTION WORKSHOP
- 12. Tested Scheduling Policy(2/4) Some simplifications Client1/ 2 Net1 serv1 Net2 Client 2/2 client router server Local Priority (P) and Cost (C) Global Deadline (D) and period (T) Local Priority (P) and Cost (C) Local Priority (P) and Cost (C) Local Priority (P) and Cost (C) Local Priority (P) and Cost (C) • Utilization based test • The evaluation assumes T=D and fixed priority (RMA) assignment ▫ Each local deadline is calculated • Each node runs a periodic enforcer ▫ It allows analyzing each flux in a node as local. REACTION WORKSHOP 12
- 13. Tested Scheduling Policy(3/4) Partitioning tasks on different JVMs (T=D) 1. Global check based on global utilization To check if it fits or not in advance 2. Sort all your tasks according to utilization To avoid allocation anomalies 3. Assign a task to a Node (bin packing) To select a node 4. Calculate your effective priority To use the RTSJ 28 priorities only 5. Deploy tasks in each different node Using a distributed scheduler 13 REACTION WORKSHOP 1.Feasibility 2.Sort 3. Assign. 5. Remote Deploy 4. Priority calculus Fail Ok
- 14. Tested Scheduling Policy(4/4) Additional code to be added to the policy 01: interface FlowShopSchedulables extends Schedulable{ 02: Vector getAllShedulable(); //It returns all sch. 03: } 01: interface PriorityBasedReconfigurationService 02: extends ReconfigurationService{ 03:} • The tested policy requires: ▫ A new subclass for a schedulable entity ▫ A new subclass for the reconfiguration system • In this article we provide: ▫ FlowShopSchedulables for each transaction ▫ PriorityBasedReconfigurationService to encapsulate the scheduler REACTION WORKSHOP 14
- 15. Evaluation Infrastructure • One centralnode to deploy the system ▫ In charge of the reconfiguration service • DREQUIEMI ▫ For execution • A real-time router ▫ IP priority enforcement Manager router JVM1 JVM2 JVM N A1 A2 ... 796 Mhz 796 Mhz Node 1 796 Mhz 300 Mhz 100 Mbps DREQUIEMI Jtime (TimeSys) PriorityBased ReconfigService DREQUIEMI Jtime (TimeSys) Distributed Scheduler addIfFeasible( ) 796 Mhz Node 2 Node N A1 A2addIfFeasible( ) Tester Node DREQUIEMI Jtime (TimeSys) PriorityBased ReconfigService (stub) DREQUIEMI Jtime (TimeSys) Distributed Scheduler DREQUIEMI Jtime (TimeSys) Distributed Scheduler 15 REACTION WORKSHOP
- 16. Cost tributaries Tasks andVMs • Cost increases with the number of tasks and the number of processors • Utilization, sorting, and assignment (no deployment) 16 REACTION WORKSHOP 1,E+00 1,E+01 1,E+02 1,E+03 1,E+04 1,E+05 1,E+06 1,E+07 64 32 16 8 4 2 1 Timeconsumed(us) Processors (JVMs) and Network available Feasiblity test algorithm costs 4096Tasks 1024Tasks 64Tasks 1Task 796Mhz-100 Mbps
- 17. Cost tributaries Type ofschedulable entity • Schedulable entities ▫ Real-time threads, remote objects, and async-event handlers • Each schedulable offers different performance ▫ Asynchronous event handlers have the worst allocation time • Remote allocation adds an extra cost 17 REACTION WORKSHOP 1,E+03 1,E+04 1,E+05 1,E+06 1,E+07 1,E+08 4096 1024 256 64 8 1 Timeconsumed(us) Schedulable Segments (tasks) to deploy Allocation costs depending on the kind of schedulable AsyncEvent Handler RtRO Rthread 1,E+03 1,E+04 1,E+05 1,E+06 1,E+07 1,E+08 4096 1024 256 64 8 1 Timeconsumed(us) Schedulable Segments (tasks) to deploy Remote allocation of remote entities AsyncEven tHandler RtRO Rthread 796Mhz-100 Mbps
- 18. Total reconfiguration time •Some interesting values ▫ A 1 seconds reconfiguration allows reconfiguring 64 distributed tasks • It depends on the number ▫ Of tasks ▫ Number of JVMs • All schedulables are supposed to be event handlers ▫ They bound the worst time of a thread and a remote object REACTION WORKSHOP 18 1,E+04 1,E+05 1,E+06 1,E+07 1,E+08 4096 1024 256 64 8 1 Timeconsumed(us) Schedulable Objects to allocate Total {re}configuration time 32JVM 16JVM 4JVM
- 19. Conclusions • Next generationJava-based distributed real-time systems may benefit form having an embedded infrastructure with reconfiguration facilities ▫ Similar to the one described in the article • However, one may choose the reconfiguration policy to suit specific application domains 19 REACTION WORKSHOP
- 20. Ongoing work • Toaddress other reconfiguration policies ▫ Different scheduling algorithms ▫ Mode change protocols As a way to introduce adaptation in DRTJava Impact of multi-core policies • Use of real-time OSGi platforms for reconfiguration ▫ Higher level adaptation closer to application 20 REACTION WORKSHOP
- 21. 21 REACTION WORKSHOP Distributed Real-Time SystemsLaboratory (Drequiem Lab)