Towards a real-time reconfiguration service for distributed Java


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Towards a real-time reconfiguration service for distributed Java

  1. 1. Towards a Reconfiguration Servicefor Distributed Real-Time Java*Pablo Basanta-ValMarisol García-VallsDREQUIEM 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. 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 work2REACTION WORKSHOP
  3. 3. Context & Introduction• Many real-time systems consider admission control as aoffline line feature▫ Clear advantages like exact algorithms• However more and more systems are dynamic andapplications 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 !3REACTIONWORKSHOP
  4. 4. Context & IntroductionA real-time reconfiguration service in anutshell• 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 DistributedReal-Time Specification for Java)▫ Contribution: Extensions to current APIS Real-time Reconfiguration Service Example global partitioner algorithm with some performance resultsREACTIONWORKSHOP4
  5. 5. Distributed Real-TimeJava middleware• Based on DREQUIEMI▫ Layered approach for DistributedReal-time Java Infrastructure Distribution Common Services Applications• Currently, it consists of three maintechnologies extending RTSJ▫ Based on Java’s RMI, {RT}-CORBA ,and TT tenets5REACTIONWORKSHOP
  6. 6. Distributed RT JavaQoS/RT configuration parameters• Based on the model proposed byRTSJ• They characterize▫ Application release pattern▫ Scheduling specific parameters▫ Memory parameters▫ Processing group options▫ Other internal decisions Thread-pool Connection Pool Memory Area poolQoS parameters indistribution layer Meaning in DREQUIEMIScheduling Parameters«Priority»Priority used during the up-call at theserverRelease Parameters«Release Time, Period,Deadline, and Cost»Invocation pattern at the serveraccording to the real-time schedulingtheoryProcessing GroupParameters«Release Time, Period,Deadline and Cost»Group patterns at the server accordingto the real-time scheduling theoryMemory ParametersParameters used by the garbagecollector at the serverThread PoolThread pool used at the sever tomanage remote invocationsConnection PoolConnection pool used at the client tocarry out the remote invocationMemory Area PoolMemory area pool used at the server toaccept remote invocationsportThe IP port on which the remote objectis accepting incoming messagesRemoteStubThe stub with the remote reference tothe remove objectEventCommonInt.A remote object which allowssubscriptions and may be remotelytriggered.6REACTIONWORKSHOP
  7. 7. Reconfigurationpoints• Three reconfiguration points inDistribute RT Java▫ Resources, distribution, andcomponents• Contributed reconfiguration applies toresource management/rescheduling:▫ Location of tasks in Remote Nodes▫ Processor, network, and memoryREACTIONWORKSHOP7reconf
  8. 8. Reconfiguration ServiceIntroducing Network parameters• RTSJ does not support thenetwork▫ 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.SchedulerDistributedSchedulerReal-time JavaDistributed Real-time Javauses MemoryParametersSchedulingParametersuses3ResourcesSchedulerNetworkParametersusesSerializableReconfigurationServiceusesSchedulableRemoteSchedulable8REACTIONWORKSHOP
  9. 9. Reconfiguration ServiceDistributed Scheduler• Based on RTSJ’sscheduler• It allows invokers toassign schedulables tothe task set▫ Allocation▫ Deallocation• Each schedulabledefines:▫ Release parameters,▫ memory parameters▫ Processing parameters▫ Network Parameters▫ Scheduling Parameters01: public interface DistributedScheduler02: 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:}9REACTIONWORKSHOP
  10. 10. Reconfiguration ServiceReconfiguration Service• To introduce reconfiguration onthe previous system▫ The reconfiguration process ismodelled as a real-timeschedulable• Based on that, thereconfiguration service▫ reconfiguration service =DistributedScheduler+ scheduling info forDistributedScheduler▫ The ReconfigurationService executeson top of a scheduler.01: public interface ReconfigurationService extends02 DistributedScheduler, Schedulable{03: MemoryParameters getMemoryParameters()04: throws RemoteException;05: ProcessingGroupParameters06: getProcessingGroupParameters()07: throws RemoteException;08: ReleaseParameters09: 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(10REACTIONWORKSHOP
  11. 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. withprecedence constraints).• Each end-to-end transaction (Γj | j 1..M) is defined as follows:▫ Global deadline (Dj)▫ A global period (Tj)▫ A set of jn schedulable segments {Sj1….Sjn} A local execution priority (Pjn) for each end-to-end transaction segment(Sjn). A local worst-case execution time (Cjn) for each segment (Sjn).11REACTIONWORKSHOP
  12. 12. Tested Scheduling Policy (2/4)Some simplificationsClient1/2Net1 serv1 Net2Client2/2client router serverLocal 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 assumesT=D and fixed priority (RMA)assignment▫ Each local deadline is calculated• Each node runs a periodicenforcer▫ It allows analyzing each flux in anode as local.REACTIONWORKSHOP12
  13. 13. Tested Scheduling Policy (3/4)Partitioning tasks on different JVMs (T=D)1. Global check based on global utilizationTo check if it fits or not in advance2. Sort all your tasks according to utilizationTo avoid allocation anomalies3. Assign a task to a Node (bin packing)To select a node4. Calculate your effective priorityTo use the RTSJ 28 priorities only5. Deploy tasks in each different nodeUsing a distributed scheduler13REACTIONWORKSHOP1.Feasibility2.Sort3. Assign.5. RemoteDeploy4. PrioritycalculusFailOk
  14. 14. Tested Scheduling Policy (4/4)Additional code to be added to the policy01: interface FlowShopSchedulables extends Schedulable{02: Vector getAllShedulable(); //It returns all sch.03: }01: interface PriorityBasedReconfigurationService02: 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 schedulerREACTIONWORKSHOP14
  15. 15. EvaluationInfrastructure• One central node to deploythe system▫ In charge of thereconfiguration service• DREQUIEMI▫ For execution• A real-time router▫ IP priority enforcementManagerrouterJVM1JVM2JVM NA1 A2...796 Mhz796 MhzNode 1796 Mhz300 Mhz100 MbpsDREQUIEMIJtime (TimeSys)PriorityBasedReconfigServiceDREQUIEMIJtime(TimeSys)DistributedScheduleraddIfFeasible( )796 MhzNode 2Node NA1A2addIfFeasible( )Tester NodeDREQUIEMIJtime (TimeSys)PriorityBasedReconfigService (stub)DREQUIEMIJtime(TimeSys)DistributedSchedulerDREQUIEMIJtime(TimeSys)DistributedScheduler15REACTIONWORKSHOP
  16. 16. Cost tributariesTasks and VMs• Cost increases with the number oftasks and the number of processors• Utilization, sorting, and assignment(no deployment)16REACTIONWORKSHOP1,E+001,E+011,E+021,E+031,E+041,E+051,E+061,E+076432168421Timeconsumed(us)Processors (JVMs) andNetwork availableFeasiblity test algorithm costs4096Tasks1024Tasks64Tasks1Task796Mhz-100 Mbps
  17. 17. Cost tributariesType of schedulable entity• Schedulable entities▫ Real-time threads, remote objects, andasync-event handlers• Each schedulable offers differentperformance▫ Asynchronous event handlers have theworst allocation time• Remote allocation adds an extra cost17REACTIONWORKSHOP1,E+031,E+041,E+051,E+061,E+071,E+08409610242566481Timeconsumed(us)Schedulable Segments (tasks) to deployAllocation costs depending on the kindof schedulableAsyncEventHandlerRtRORthread1,E+031,E+041,E+051,E+061,E+071,E+08409610242566481Timeconsumed(us)Schedulable Segments (tasks) to deployRemote allocation of remote entitiesAsyncEventHandlerRtRORthread796Mhz-100 Mbps
  18. 18. Total reconfiguration time• Some interesting values▫ A 1 seconds reconfiguration allowsreconfiguring 64 distributed tasks• It depends on the number▫ Of tasks▫ Number of JVMs• All schedulables are supposed to be eventhandlers▫ They bound the worst time of a thread and aremote objectREACTIONWORKSHOP181,E+041,E+051,E+061,E+071,E+08409610242566481Timeconsumed(us)Schedulable Objects to allocateTotal {re}configuration time32JVM16JVM4JVM
  19. 19. Conclusions• Next generation Java-based distributed real-timesystems may benefit form having an embeddedinfrastructure with reconfiguration facilities▫ Similar to the one described in the article• However, one may choose the reconfiguration policy tosuit specific application domains19REACTIONWORKSHOP
  20. 20. Ongoing work• To address 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 application20REACTIONWORKSHOP
  21. 21. 21REACTIONWORKSHOPDistributed Real-Time Systems Laboratory (Drequiem Lab)